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ABSTRACT 


This report details generic functional requlrenenta for a 
general-purpose, multi-mission Data Base Management System (DBMS) for 
application to NASA's remotely sensed scientific data bases. The 
motivation for utilizing DBMS technology In this environment are 
explained. The major requirements Include: (1) a DBMS for 
scientific observational data, (2) a mul tl'^ m Is slon oapability, (3) 
user-friendly, (4) extensive and Integrated Information (ibout data, 
(^) robust languages for defining data structures and formats, (6) 
scientific data types and structures, (7) flexible physical aocesn 
mechanisms, (8) ways of representing spatial relationships, (9) a 
high-level nonprocedural interactive query and data manipulation 
language, (10) data base maintenance utilities, (11) hlgh-rate 
Input/output and large data volume storage, (12) adaptability to a 
distributed data base and/or data base machine conf ,1 j'^ura tlon, and 
(13) well designed and supported. Detailed functions are specified 
in a top-down hierarchic fashion. Implementation, performance and 
support requirements are also given. 
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SECTION 1 


INTRODUCTION 

"The purpose of a programning system Is 
to make a computer easy to use." 

-- Brooks 


1.1 QB.JBCTIVE 

The objective of this document Is to define detailed functional 
requirements for a general-purpose, multi-mission Data Base 
Management System (DBMS), called the Applications DAtabase 
Management System (ADAM). The ADAM System Is Intended lo 
provide DBMS support as one component of the ground data 
management systems of future missions of the Office of Space and 
Terrestrial Applications (OSTA) of NASA, and possibly for use by 
related NASA Offices and/or agencies that collect, archive, 
process, or distribute remotely sensed scientific data about the 
earth . 

1 .2 MOTIVATION 

Generic requirements for NASA DBMSs need to be documented for 
several reasons. First, there has been considerable controversy 
within NASA as to whether DBMS technology can satisfy the data 
management requirements of NASA applications. By specifying 
those requirements most relevant to DBHS technology, both NASA 
data managers and the DBMS community can more precisely assess 
the suitability of DBMS for any given application. Second, 
detailing the requirements In written form will help NASA and 
commercial vendors to Isolate those features that can, and 
cannot, be provided by commercially available DBMS software. 
Action can then be taken by NASA or (preferably) by the vendors 
to augment, alter, or replace current DBMSs with systems more 
suited to NASA/OSTA applications. Finally, these requirements 
can serve any NASA application (for example, a future flight 
mission) as a checklist from which to draw requirements for 
near-term procurement of the best available DBMS to suit <that 
application. 

1.3 s cm 

It should be emphasized that these requirements are for a 
general-purpose tool for data base management, which may support 
-- but is not intended as -- a complete "turn-key” application 
system such as a geographic Information system for Landsat 
Imagery. DBMS requirements for a particular NASA application 
have been documented before, for example, for the Integrated 
DBMS of the NASA End-to-End Data System (NEEDS) project [GARY 
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80]. Hou«ver» 4LfiXll£liEL DBMS requlreDents for an Indefinite 
variety of NASA scientific applications have never been 
specified . 

As nuohy this report contains the "greatest oooDon denominator" 
requirements. It is intended to be a baseline document that may 
be altered by applications as needed and that will be updated 
periodically based upon future NASA/OSTA experience with DBMSs. 
The requirements contained herein will not suit all 
applications, especially real-time systems or "pipeline" data 
processing systems (such as the Landsat Image Processing 
Facility) where throughput rates are paramount. For any given 
application, not all requirements will pertain, nor will this 
list be exhaustive. However, every attempt has been made to 
reference each functional requirement to one or more known user 
requirements. Finally, the performance of such a general- 
purpose tool is difficult if not impossible to specify in 
absolute quantities, since it is dependent upon the data to be 
managed and the user response requirements of the individual 
application. Although some baseline performance figures will be 
available soon from a few operational DBMS applications 
CGOtIG 81], no standard NASA benchmarks are available for testing 
DBMS performance. 


1.4 


The ADAM System is Intended to be a general-purpose tool that 
oan be adapted to mcry different cpplloatlons occurring in 
varying data processing environments. Therefore^ there does not 
exist a specific list of computer hardware and software on which 
the ADAH must be implemented. Bather, the goal is to achieve 
maximum Independence from the constraints posed by the 
environment of each application, so that ADAM is transportable 
between different systems to the maximum degree allowed by the 
present state of the art. 

1.4.1 V,5£.R 

The users of ADAM are anticipated to be both discipline 
scientists -- those well versed in the fields of oceanography, 
atmospheric or earth sciences, earth resources, etc. -- as well 
as computer analysts and programmers that will be developing 
applications programs and systems to be supported by ADAM. More 
specifically, potential users will Include [GARY 60]: 


o Principal investigators associated with specific 
missions and/or research programs 
o Investigators analyzing single- or multi-source 
data 

o Scientists developing models of physical 
phenomena 
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Reseaohers in la^ge prooesalng and other data 
analyala 

o Developnent progrannera reaponalble for teatlng 
and debugging data prooeaalng and data analyala 
aoftware 

0 Other applloationa aoftware developnent peraonnel 

MIA 1UL& 

The apeoirio data aeta to be nannged by ADAM will be different 
for each application ayatom. However^ oharaoterla tlo NASA/OSTA 
data typea that ADAM will have to accofflmodate Include [GARY 80] i 


o 

0 

o 

0 

0 

0 

o 


Digital Image data 

Spacecraft XJk aitu meaaurementa 

Data collected by ground aenaora 

Reaulta of application data analyala programa 

Geophyaloal parametera extracted from all of the 

above types of data 

Application modeling reaulta 

Information describing data set characteristics 


1.i|.3 APPXIi^ATJON . SYSTEMS AND PROGRAMS 


An ADAM Will need to serve a variety of application 
ayatems/programs. These programs will, In general, be 
developmental and Ajd ho c , rather than operational production 
programs that are run on a routine basis. Examples of the 
expected types of application programs are listed in Table 1.1. 


1«5 RELATION TO OTHER NASA DBMS EFFORTS 

For the reasons outlined In Section 2 below, there has been 
considerable Interest within NASA of late In DBMS technology. 
Prior to 1978» DBMSs were used within NASA exclusively for 
administrative types of data bases [BRDK 60]. Several on-going 
tasks within NASA now have used or plan to use DBMSs for 
scientific, remotely sensed data. The paragraphs that follow 
attempt to relate concisely the ADAM to the perceived objectives 
of these other efforts. 


The Packet Management System (PMS) at Goddard Space Flight 
Center la probably the effort most closely related to ADAM. Its 
near-term emphasis Is upon testing the suitability of 
commercially available DBMSs (specifically, Oracle and SEED) to 
a number of applications. One of these applications Is managing 


T«bX0 1 - 1 . ExftBpIes of Potential Application SyataBs/PrograBa 

ProaraM Tvoa EaraBDla/Pasoription 

CuBtoaized data aocesB 

0 Data set loading and appending of new data 
0 Locating data required 
0 Display of selected portions of data 
0 Data retrieval and filtering of unwanted data 
o Menu-driven (paraaetrio) Bystaas 

Data processing 

o Algebraic and functional operations 
o Algorithm development and application 
0 Geophysical parameter extraction 
0 Data product generation 

Modeling and Forecasting 
o Finite element models 
o Differential equation models 
0 Simulations 

Image display and processing [BLOK 80 ] 
o Geometric transformations or reprojeotions 
0 Rotation and magnification 

0 Combination (mosaiclng) 

0 Annotation and display 

0 Local operations 

0 Point operations 
o Algebraic operations 


o Correlation and convolution 


0 Frequency domain computation and filtering 


o Image measurement 


o Test image 


Differing map projections 
Rotation, magnifloatlon, and 
shrinking 

Combination of adjoining Images 

into larger ones 

Add, alter, or remove labels or 

symbols 

Blemish correction or removal, 
image segmentation 
Contrast manipulation 
Add, subtract, multiply, 
divide, average, etc., either 
between images or with 
constants/ variables 
Comparison and registration of 
Images from different 
instruments, filters to sharpen 
features or remove noise 
Fourier transforms for 
Identification of image 
components, coherent noise 
removal, enhancement of 
specific frequency components 
Extraction of arithmetic and/or 
statistical characteristics of 
imagery 

Creation of te>?t images, grids, 
noise patterns 
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TabXt 1-n 


Exaaplea of Potontlal Applloation Systoss/Prof r«MS 
( 00 nt) 


Ifrogni Is Jit Ixaaplo/DoaorlDtion 

Statistical Fu notice >8 
0 Interpolation 
0 SBOothlng 
0 Averaging 
0 Klstogran production 
0 Correlation 
0 Linear regression 
0 Analysis of varitnoe 


Graphics 

0 Map generation 
0 Contour plots 

0 Graphs of geophysical paraaetors over tiae 
o HistograBfS 
0 Scatterplots 


a catalog of the physical storage granules -- or packets -- that 
will be received in near-real- tl ae froa spacecraft sensors at 
rates up to 50 aegabltr per second (but with only a 20$ duty 
cycle). The packets w.,11 be archived in the Archival Mass 
Memory (AMM) that is under development at Marshall Space Flight 
Center under the NASA End-to-End Data System (NEEDS) Project 
within the Office of Aeronautics and Space Technology (OAST), 
Although the PMS plans include a direct Interface to the end- 
user (e.g.| a scientist), to application programs that may 
return mere processed data to the archive, and access to the 
data Itself, the initial thrust is upon cataloging the Level 0' 
and 1 data stored in the AMM [BURN 80). • The functional 
requirements for the NEEDS DBMS [GARY 80] stress the detailed 
attributes of a data set that need to be cataloged to help the 
user locate data of interest, with less emphasis upon functions 
supporting access to the data Itself (such as logical views of 
the data tailored to users via a subsoheaa definition language)^ 
The ADAM is more oriented toward the user interface than the 
data collection aspect, toward non-real-tiae rather than real- 
time environments, and toward DBMS access to smaller data 
volumes in response to types of queries. It is 
conceivable, for example, that ADAM might interface with the PMS 
in order to select and retrieve data of Interest for more 
processing or for more intensive study by scientists. 


* For a definition of these data levels, see [DJRD 79] 
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Tht Pilot CliaotoDatft Base Nanagoaont Systea (PCDBHS)) 
sponaorad by tho Office of Space and Terreatrlal Applications 
(OSTA), Is applying the PMS evaluation to the requireaents of 
the oliaate discipline within OSTA [OAOC 79]« This near-tera 
lapleaen tatlcnr like others discussed belowp should help to 
define user and functional requireaents for data aanageaent 
tools such as ADAM. 

The OSTA Data Inventory and Catalog task is collecting the 
necessary inforaatfion about existing data seta to Incorporate 
into a cataloging systea to be aalntained on-line by the PCDBMS. 
The ADAM is Intended as a tool that is used to aaintain and 
access this kind of Inforaationi ns well as soae of the data 
that it describes. Although ADAM effort also included an 
asaessaent of representative existing data bases and data 
aanageaent systeas CAPNY 81]| the intent was to distill their 
coaaon characteristics as factors that influence the 
requireaents for ADAM, rather than to perforn an exhaustive 
survey of all data seta as an end in Itself. 

Also under development by OSTA Data Systems is the Transportable 
Applications Executive (TAE)t an executive that will provide a 
standard interface to user application software, and facilitate 
both expert and casual user Interaction with the system. A 
prototype TAE has been implemented that supports a subset of the 
ultimate TAE services, including user menus, a command language, 
a parameter selection facility, and an on-line help facility. 
The TAE -- like ADAM -- is intended to be multi-mission, 
transportable software. In systems where the TAE is the 
executive with which ADAM must interface (see Function i|,2. 
Appendix A), the TAE vill help to standardize the interface to 
the hardware and all other TAE-compatible software, thus 
simplifying the ADAM Interfaces [BCHM 81]. This is particularly 
true, for example, of the Interface with the image which TAE is 
based. 

The Applications Data Service (ADS) Project of OSTA Data Systems 
is supporting a standards-development activity and three pilot 
data systems that impact ADAM. The ADAM System subtask to 
assess DBMS standards and standards-set ting activities [URNA 
81B] will aid the overall ADS standards wortc^ and in return the 
standards developed by ADS should simplify the Interfaces of the 
ADAM with users, storage devices, the ADS network, etc. The 
pilot systems, and particularly the Oceanic Pilot System (OPS) 
at JPL, will help to refine user and functional requirements for 
data management and to serve as a testbed for gaining direct 
experience with the promise and problems of existing DBMSs. The 
requirements contained herein define a target DBMS that is 
tailored to the requirements of future systems which are 
exemplified by the pilots. Therefore, the pilot systems are 
also prime candidates for prototype implementations of the ADAM. 
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Finally, fche DBMS prototype and the Hark IV Data Reoorda Syaten, 
under development at JPL for the Flight Projeota Support Office 
(FPSO) in aupport of OSS (Office of Space Sciencea) alaalona, ia 
another example of a ayatem that la uaing a commercially 
available DBMS (Unlvac’a DMS 1100) for a near-term 
implementation. It too has already provided valuable experience 
in the advantages and disadvantages of DBMS technology. In 
particular, the completed prototype demonstrated the feasibility 
of direct DBMS access to Level 0 and 1 telemetry and engineering 
data. It also verified user requirements for several 
capabilities that are uniquely provided by DBMSs, such as data 
Independence, inter-relation of files, and multi-key access to 
dat^ (APNI 81). 


1 .6 ,QV£J,YI£I 01 IM£. DQSMMl 

The rest of this document contains the functional requirements 

for ADAM that yere derived from: 

o the requirements of users [DJRD 79, FJMT 81, OAOC 79, LHNN 
80A]; 

o the characteristics of existing OSTA and related data bases 
[APNY 81, BRYN 79A, BRYN 79B, JHNS 80]; 

o existing standards that were deemed relevant '4o DBMSs [URNA 
81 B]; and 

o Inputs from related efforts such as the NASA/OSTA Data Base 
Management Systems Panel [BRYN 79A, BRYN 79B, LHMN 80B, URNA 
8lA], and the NEEDS effort to define functional requirements 
for a DBMS for a particular environment [GARY 80]. 


Section 2 first discusses the applicability of DBMS technology 
to NASA/OSTA problems and inefficiencies. This section answers 
the question, "When?” or "Under what circumstances?". Section 3 
then gives an overview of the major requirements upon ADAM. 
This section is intended to answer the question "What?" Section 
1| contains the implementation ohara<^iterlstlcs that are required 
of ADAM, answering the question "How?" Sections 5 and 6 specify 
the performance and support that is required of an ADAM, 
respectively, to answer the question "How well?" Appendix A 
concludes the document with a detailed discussion of the generic 
functions that ADAM will need to perform. The 
hierarchical breakdown 


utilizes a 
analysis" . 


called a "top-down 


exposition 

functional 
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SECTION 2 


DBMS APPLICABILITY TO NASA/OSTA DATA BASES 

"The user does not know what he 
wants until he sees what he gets." 

— Yourdon 

The growing slae and ooaplexlty of OSTA data bases has created a 
nuBber of probleps and Inef f lolences In how data la managed. The 
Idea of using n DBMS for NASA's applications data bases 
originated from similar problems and Inefficiencies in private 
Industry that were largely solved by the devolopment and 
Implementation of DBMS technology. What follows is a brief 
dlsbusslon of each of the problems and Inefficiencies, the 
capabilities that DBMS technology offers, and how each 
capability contributes to the solution of each problem and/or 
Inefficiency. 

2 . 1 PROBLEMS 

The problems which follow have Impacts that are difficult to 
quantify but nonetheless Interfere to a great extent with the 
accomplishment of OSTA goals. Many of these problems were 
Independently Identified by a major National Academy of Sciences 
study [BRNS 80]. 

£1: Lack of Coordination and Communication. Because 

each mission within each NASA Office has generally been 
responsible for developing data management systems to support 
Its unique requirements, the concommitant lack of coordination 
and communication between missions has hampered: 

o Standardization. No official standard NASA formats or 
software could be located by this or related tasks 
tKUCH 81, URNA 8lB], although attempts to specify 
standard NASA formats are now underway [EDC 79, GDNU 
79» WLTN 80, GRNB 81]. Alao^ some widely used systems 
(e.g., AOIPS, VICAR [APNY 81]) have formats that have 
become almost facto standards [URNA 81B]. 

o Economies of Scale and Cost-Effective Trade-Offs. 
Virtually every OSTA system examined to date by this 
task performs in Its own way the routine functions of 
structuring, storing, and retrieving data [APNY 81]. 
Mission software managers are understandably reluctant 
to expend their very limited resources to develop 
general-purpose software that can be used by other 
missions. The efficiencies of multi-mission software 
are obvious from the global NASA perspective, but not 
from the missions' local perspective. 
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0 Adaptability to Change, Moat ayatena that 

examined by thia taak were inplenented in FOBTRAN or 
inaohine language CAPNY 8l3> Sugh languagea alaoat 
always soatter throughout each program the atateaenta 
whioh define the structure of the files that they 
create or aooeas. When errors in these stateaents are 
found, or the requirements for its use change, 
software developers are faced with the dileaaa of 
either suffering serious manpower costs to find and 
alter all the relevant format atateaenta, or enduring 
frozen designs which simply do not permit support of 
the changing requirements. 

0 Centralized Integrity and Security Constraints. In 
the systems that we examined, provisions for integrity 
and security of data sets are quite decentralized. 
Generally, the principal inveshigator(s) that 
collected the data set enforce security only by 
deciding to whom copies of that data may be sent. 
They have little or no control of the data beyond 
that. Except in formal archive centers, individual 
investigators maintain their own backup copies of 
their copy of a data set. This can easily lead to 
redundant or inoonsistent backups of the same data 
set. Furthermore, these investi/{$ators must assume the 
responsibility for locating and accessing any related 
files that may be compared for validating the 
correctness of data in a data set. 

Proble m Pg i Difficulty in Finding Useful Data, One of the few 
user requirements that was identified by every OSTA discipline 
at the OSTA Data Systems Planning Workshop [DJRD 79]| and which 
is commonly mentioned by actual interviews with users [OAOC 79» 
FJMT 61, LHMN SOA], is the need to enhance their capabilities to 
locate data which is both available and of "good quality". 

Prob lem £3.; Difficulty in Accessing Relevant Data. Another 
problem that is widely mentioned is the difficulty of 
efficiently accessing the portions of data which are relevant to 
a particular application, based upon multiple keys (e.g., 
latitude, longitude, time, and sensor [OAOC 79, LHMM SOA, FJMT 
813). Except for small data bases covering regions of intense 
interest, OSTA archives are stored chronologically on magnetic 
tapes. Hence retrieval of all the data for a new request 
pertaining to a partioular region involves reading through many 
tapes and maybe even the entire data base in order to find a 
small percentage of relevant data. This is a slow process even 
if catalogs or indexes help the user translate his request into 
orbit numbers and hence tape reel numbers [APNY 81]. 
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The piN'^ooeas la aufflolently oluisiay and expenalve that It often 
llpilta aoientlflo inquiry to thoae queatlona for which acta la 
readily available, and exoludea other worthwhile Inveatigatlona 
that Bight be poaaible from the aase data baae. 

ZHitilLljBiA £il: Inoreaaing Quantitlea of Data. laproved aenaor 

technology haa reaulted in aenaora which are returning data at 
ever-inoreaalng ratea, with no change in that trend projected 
for the foreaeeable future [BRNS 60]. For exaaple, the Theaatlc 
Mapper Inatrument to be aboard the Landaat D/D' Spacecraft alone 
will collect data continuoualy at a rate of 85 Begablta per 
aeoond. Thia haa reaulted in an exploaion in data baae alze -- 
a projected blta for Landaat D', aaauBing a llfetlBe of 5 

yeara -- and bottleneoka in proceaaing that data in a tiBely way 
[BLLN 81]. The data ratea Inoreaae by a factor of 2 to M for 
Multlspeotral Linear Arraya (MLAa) and Synthetic Aperture Radara 
(SARa) to be flown on future earth obaervatlon aatellitea [BRCK 
80 ], 

■ProPleB £5.: Protecting Data. In order to enaure that no data 

Is Inadvertantly loat or deatroyed during proceaaing and 
**Qleaning" of the data, many redundant oopiea of entire fllea 
are kept, even when ohangea are aade to only 1 to 5 % of the 
records in th^ae filea [APNY 81 J. Thla unneoeaaary redundancy 
has merely exacerbated the growth in data base size (Problea 
P4) . 

Proble a ££.: Conflicting Access Rights. When data is still 

"new^, a small set of principal investigators need to be granted 
exclusive access to that data for a Halted time. Subsequently, 
NASA/OSTA would like to encourage the widest possible 
distribution of that same data. This seeming paradox between 
very strict and very free access rights to the data has in the 
past led to systems developed by and for alsslon principal 
Investigators onl v ^ with data bases becoming "orphans" in 
archival data centers after the termination of that mission 
[DJRD 79, APNY 81 ]. 

In addition to the above problems, the current approach to data 
management utilizes manpower inefficiently. The Inefficiencies 
which follow may be hidden in the form of decreased programmer 
productivity, new programs that could not be written, sclentiflo 
analysis that had to be foregone, etc. Each inefficiency 
results in the increased use of manpower as a way to minimize 
expenditures for use of computer hardware. Overall costs 
Increase, therefore, because of the trend throughout the 
information systems Industry toward rapidly rising costs for 
people and the software they generate, coupled with falling per- 
unit costs for hardware [ZLKW 78]. 

Inefficiency XI: Redundant Software Development. As mentioned 

in Problem P1 , OSTA missions have developed all their own 
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aoftware, usually embedding routine data management aspects 
within applloatlon-speoif lo programs. Many of the data 
management functions described later In this document are common 
to all OSTA data systems, but are currently performed by custom 
software tAPNY 61]. Again, no one mission wants to develop 
multi-mission data management software, yet the inefficiency of 
this redundant development should be apparent. 

Inefficiency 12 ! Software Maintenance. It has been estimated 
that over two-thirds of all software development costs In 
Industry are spent maintaining existing software [ZLKW 78]* 
Softwarti maintenance costs have generally been highest where a 
machine language rather than high-level programming language has 
been used [ZLKW 78], and where functions such as data management 
have not been centralized Into one Identifiable module. NASA Is 
probably no exception to this Industry-wide trend. And In this 
time of tightening budgets, funds spent for maintenance are 
funds taken from the development of new software or from 
scientific analysis. 

Inef f loien o V 13.: Adapting Software to Changing Requirements. 
Inevitably some requirements on any data system change during 
Its lifetime [ZLKW 78 ]. However, the dispersion of file formats 
among application programs within OSTA data systems may make any 
changes too expensive to Implement or too time-consuming to meet 
critical mission milestones. As a result, requirements and file 
formats must be frozen early In the design of the system, or 
else considerable effort must be expended determining what 
portions of the system will be affected by necessary changes. 
Once data collection has actually begun, system Inflexibility 
becomes even greater. This was the case, for example, with the 
Seasat mission [BRWN 80]. 

2.2 DBMS CAPABILITIES 

A Data Base Management System (DBMS) Is responsible for all 
access to, and updates of, the files contained In Its data base 
(See Figure 2-1). DBMS technology evolved due to problems and 
Inefficiencies similar to those listed above that were 
experienced by commercial data base users. The reasons for the 
development of data base concepts are not Invalid a ted Jiy: the 
types six data found ia HA&A data bases . The evolution of DBMS- 
based systems from f lle-orlented systems Is shown In Figure 2-2. 

The capabilities of DBMS technology are briefly described below. 
Further details may be found In [CRDN 79i DATE 77> MRTN 761 
etc.]. The OSTA problem and/or Inefficiency which each 
capability addresses Is marked by an "X" In Table 2-1, with an 
"M* denoting Its main intent. 

Capability Q 1 : Data Independence. This term refers to the 
insulation of the user from the physical details of how and 
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where each data record la atored (See Figure 2-3)» The DBMS 
acta aa a "alddle- nan" between the uaer and the data atorage 
media, much aa a o3erk in an auto parta ctore helpa ouatomera 
locate the part(a) that they need. The cuatoaera ahould not 
have to be aware of how the atore organlzea ita ahelvea (e.g., 
by part number), and ahould be Inaulated from any ohangea to 
thla organization. Rather, he or ahe should need only to 
deaorlbd the l oaioal oaram e tera (oar make, year, part type, 
etc.) of the needed part. It ahould be the olerk'a 
reaponalbillty to tranaform thoae parametera ihto a part number, 
and from that to a particular ahelf and box number where the 
part la located. 



Figure 2-1. Schematic of an Integrated Data Baae Syatem 
[CRDN 79 ] 


Capability Data Shareablllty and Nonr edundanoyu Two of the 
major goals for OSTA's Applications Data Service (ADS) that were 
determined at the OSTA Data System Planning Workshop are 
increasing data sharing and reducing data redundancy [DJRD 79 ]. 
By centralizing control of all access tc and updates of a data 
base, a DBMS provides a focal point for all users requiring data 
from the data base. A DBMS acts as a "traffic cop", allowing 
multiple users to access the same data simultaneously so long as 
it does not interfere with other users (e.g., those who might be 
updating the data). By permitting different user views of, and 
names for, different subsets of the data base, a DBMS provides 
to a user only the data items needed in the format required, 
without each user having to retain redundant copies (see Figure 
2-k) . 
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Table 2-1. OSTA Data Kanagenent Problema (P) and Inef fioienolea 
(I) That Are Addresaed by (X)^ or the Main Purpose 
of (M), DBHS CapablUtlea (C) 



X - DBMS CAPABILITY ADDRESSES PROBLEM 


Qapablllty C^! Relatability. The major characteristic which 
distinguishes a true d at a bapf from a collection of files is the 
explicit or implicit relationships which link the files into a 
structured data base. For example, each spacecraft has one or 
more sensors, each of which collect observations that are 
generally stored as separate files. The spacecraft also has 
engineering and location information (such as epheuerldes 
tables, spacecraft attitude, etc.) that may be relevant to all 
of the sensors* observations in ways that vary by sensor. 
Furthermore, one sensor may have multiple data files, containing 
observations that were collected at different ground stations or 
have undergone varying stages of processing (e.g., raw bit 
stream vs. engineering units vs. geophysical parameters). These 
relationships are shown graphically in Figure 2.5. 
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Capability Integrity. Integrity refers to the oorreotneaa 
of data values and rela tionahlpa in the data base* The DBMS 
capability to protect data baee integrity la largely drawn froa 
the previous two capabilities: by centralizing control over and 
relating various data Iteas that were foraerly dlsperaedi a DBMS 
can aonitor for Inconsistencies to known relationships, 
unreasonable values based upon other observations, etc. 
Furthermore, It can promulgate changes which affect related data 
items, some of which might not be known to the user who makes 
the change. 

Cajpabi li ty £5.: Access Flexibility. Programming languages, 
using the basic access mechanisms that are offered by the 
resident operating system, enable the user to efficiently access 
a file using a single key (e.g., record number). However, most 
user queries or requests for data from a user program specify 
multiple keys [OAOC 79» FJMT 81, LHMN 80A], for example: *>Find 
all sea surface temperature data in the region 30N to 3 ^N 
latitude and 1it2H to 1i)7W longitude on 7 July 1 977"« This 
example has three distinct criteria or keys: geophysical 
parameter (sea surface temperature), region (latitude and 
longitude), and time (date). DBMSs permit access of any part of 
the data base on the basis of many possible access keys, in a 
way more efficient than generalized file management systems can. 

Capability Security. Because tho IBMS alone is responsible 
for all access to the data base, it can as^iign, control, and 
remove the privilege of any user or application program to 
access any portion of the data base. Most DBMSs also have the 
capability to limit the functions that any individual may 
perform on a portion of the data base. For example, it can 
allow a principal investigator, as the creator and "owner* of a 
data file, to restrict access to that file to only himself and 
those whom he authorizes, and to restrict updating of that file 
to only his assistants. As with Capability C4, the DBMS can act 
as a "policeman", enforcing security constraints that protect 
the data from malioious or inadvertent intrusion. 

Capability £1: Performance and Efficiency. As the data files in 
a data base grow, classical exhaustive searching for data of 
Interest becomes much less efficient than the multi-key apcess 
mechanisms provided by a DBMS. Similarly, copying an entire 
file in order to change only M of its records is a more 
inefficient use of computer capacity than is the update-in-place 
capabilities provided by most DBMSs. Consolidation of routine 
data management operations into one module facilitates the 
optimization of the algorithms and machine statements which 
perform those operations. For example, the builders of VICAR 
found that by developing a centralized READ module that was 
tailored to the application, they could halve the time required 
to read a file using the standard FORTRAN READ command [APNT 
81 ]. 
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iLiJtlJllIlJlcJC ££i Data Baaa Structuring, Adalnts tration, and 
Control. Tha data baaa oonoapt traata all data aa a pool of 
Inforaatlon froa which aany dlffarant uaara draw out and return 
data. Thla global parapaotlva Inoludaa defining the 
raqulraaanta and daalgn of the entire data baae, aa well aa 
adalnla taring and controlling tha data baaa, for the overall 
good of tha organisation rather than aooordlng to the intereata 
of a few Indlyiduala who create the fllea. In a data baae 
anvlronaent, theae functlona can be veatad In a a ingle 
Individual (or group) called the Data Baae Adolnlatrator (DBA). 
The DBA can anaure, for axaapla, that data files generatad by 
dlffarant organizations (a.g., Blsalona) are conpatible and in a 
fora Boat usable to tha aajorlty of users (e.g., all aclentiats 
In a discipline). 

2.3 ££m 

The DBMS capabilities described above are not without their 
oonooaaltant costs. The design of the Internal structures In a 
centralized data base aay favor soae application prograas at the 
expense of others. For exaaple, a chronological organization of 
spacecraft data would favor those programs that process data for 
a single orbit of the spacecraft, at the expense of programs 
needing all data for a patlcular geographic area. "Binning" the 
data aooordlng to geographical regions would, conversely, favor 
the latter over the former. However, this Is a data base design 
Issue that besets any data management system, not Just a DBMS, 
whenever redundant data bases with different organizations are 
not permitted. 

The creation and maintenance of the many Inter-rela tlonshlps and 
multiple access paths peraltted by a DBMS Impose both space and 
update time overheads. These overheads may vary from 10 to 20 
percent depending upon the number of keys and relationships 
chosen for that application [CRDN 79], 

While a general-purpose, flexible software package such as a 
DBMS reduces overall programmer time cost to develop a given 
application system, the resulting system generally Is less 
efficient with a aohlne resources than Is a system tailored to 
that application only. Furthermore, the ease of adding new 
applications using a DBMS often results in higher total system 
cost because acre applications will be Implemented [CRDN 79]* 

The cost-effectiveness of a DBMS approach must be Judged upon 
the functions performed per life-cycle dollar expended, 
ipoludina manpower (programming) costs. With the rapidly 
Increasing cost and scarcity of skilled computer personnel and 
the decreasing per-unit cost of computer hardware, DBMSs have 
proven cost-effective In the larger commercial applications. 
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i.n mutamsioits sat cfins iPPLiciaiiTY 


Th* data aanagiBant prablaas and inaf f lolanciaa that wara 
dlsoU 80 «d In Section 2,1 above have been found to be oonmon to 
■oat NASA/OSTA and related data ayatena. Thla Inoludea data at 
M.XMLX XAIAJI AX A£AAAJ1A1AA* There exlat exanplea of the 
exploitation of the DBMS oapabilltlea outlined In Section 2,2 
above on every level of data known to NASA, lAAlJiilAA L evel Q, 
AiUi IMMKX data [APNY 81]. 

However, DBHSa are beat aulted to applloatlona where aeveral of 
their oapabilltlea are required. In NASA, theae tend to be data 
distribution ayate«a, characterized by oooaaional jiil hoc 
aooeaaea by a large nuaber of uaera, baaed upon aultlple aooeaa 
criteria that are In ter- related. The dlaolpllne-orlented 
archival ayateaa being developed aa pilot ayatena for the 
Applloatlona Data Service, aa well aa Boat the ayateaa 
dlaouaaed In [APNY 81], are excellent exaaplea of thla type of 
ayatea. 

Applloatlona thi^t are generally not aulted to DBMS uae include 
apeolal-purpoae, real-tlae, and/or ’’pipeline^ data proceaalng 
ayateaa auoh aa the laage Proceaalng Facility at Goddard Space 
Flight Center. Such applloatlona typically apply a fixed 
algorltha to a contlnuoua atreaa of Input data, rather than 
having a variety of application prograaa that have different and 
changing requlreaenta for portiona of the data baae that are 
aeleoted baaed upon aore than one key. With theae production- 
oriented ayateaa, It la unlikely that the flexibility of aooeaa 
offered by a DBMS would be worth Its expense. 



SECTION 3 

OVERVIEW OF REQUIREMENTS 

"No orafti^man, if he aspires to the highest 
work In his profession, will accept [Inferior] 
tools; and no employer, If he appreciates the 
quality of work, will ask a oraftsma,<i! to accept them." 

-- Weinberg 

"If the programmer Is working In 
a language thtit allows only 
three dimensions, we are not likely 
to observe more than three." 

— Weinberg 


This section gives an overview of the ADAM functional 
requirements which are detailed in the rest of this document, as 
they relate to the perceived user requirements for data 
management [FJMT 81]. 

Throughout the remainder of this document, requirements of the 
form "The ADAM System shall. may be replaced by "The ADAM 
System shall, or shall be conveniently modifiable or augmentable 
to,...". No single DBMS can satisfy all of these requirements 
at present, but virtually all of the following requirements are 
satisfied by at least one existing DBMS. 

3 . 1 MlSiS SCIENTIFIC OBSERVATIONAL DATA 

NASA applications users require simpler, more standardized, more 
rapid, and more flexible access to observational data that is 
residing In diverse formats at diverse locations [BRCK 80, DJRD 
79, FJMT 81, LHMN 80A, LHMN 80B, LOTS 79A, OAOC 79, OFNS 79]. 
As discussed In Section B, most of these objectives are met by 
the use of a data base management system (DBMS). And most 
existing DBMSs are designed for applications to the commercial 
rather than to the scientific sphere. 

The Applications DAtabase Management System (ADAM) shall perform 
as a software tool for access to public archives and private 
files containing scientific and engineering data. The ADAM Is 
Intended to perform routine data management functions that are 
common to most data management systems of near-earth re:niote 
sensing missions of NASA's Office of Space and Terrestrial 
Applications (OSTA) and related Institutions. It will not 
accomplish any specialized processing that may be under 
development by, and/or peculiar to, any particular application, 
although It should pro«vlde support and software interfaces to 
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suoh routines. The data which It manages may Inolude raw bit 
streams (Level 0 data) as well as any level of processed data or 
data products (data Levels 1, 2, 3 m**)>* 

3.2 MULTI-MISSION TOOL 

Currently every mission designs and builds Its own data 
management system from soratoh [APNY 81, BRNS 80]. The cost of 
doing this will soon become prohibitive^ and is the major 
Impetus for developing multi-mission Information systems. 

The ADAM is Intended to be a tool that uay be readily employed 
in, and adapted to, the data systems of most future OST-A 
projects; It is not to be a "turn-key" component of any extant 
or proposed mission. As such, ADAM must be; 

Tra nsport a ble - The ADAM software may be Implemented on 
different brands of computer hardware having different 
operating systems and assembler languages. Hence the ADAM 
should Itself be written in a standardized, transportable, 
high-level language and should minimize and concentrate in 
minimal set of modules its interface with any operating 
system . 

■Mjgdular aM Expandable - A minimal core of essential data 
management functions should form the nucleus of the ADAM, 
and shall be Implementable at least on minicomputers or 
larger machines. Additional c a pa b i 1 1 1 1 e s su o h as 
telecommunications and image data handling shall be readily 
appendable as modular enhancements to this system nucleus. 

Flexi ble - Changes to system parameters, commands, data 
structures, formats, functions, etc., must be simple to 
accomplish, have minimal impact on other ADAM components, 
and must not require inordinate amounts of human or 
computer resources. Both public archives and private, 
user-defined data bases may be maintained by ADAM. 

3.3 tfSEK-FBIEHDLI 

There is a wide variety of potential users of OSTA data, ranging 
from programmers who are developing programs to scientists who 
are unfamiliar with computers and occasionally wish to find some 
data that is correlative to their own [APNY 81, FJMT 81]. 

The AD AM must therefore be easy for the programmer and non- 
programmer alike to use. The system should be easy for the 
uninitiated user to learn. It should be able to free the user 
from the often confusing and repetitious tasks of data 


* For a definition of these data levels, see [DJRD 79]. 
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buffering, file aanagenent, dlak and tape 
nounts/dlsmounte/posltlonlng, label ppooeiialng, and applications 
or analysis program parameter processing. 

The command language of ADAH must be a high-level, Engllsh-llke 
set of verb-object predicates that are easy for users to 
understand. Interactive, hoc queries as well as routine 
requests for data from application programs written In any of 
several standard "host" programming, languages (such as FORTRAN, 
PL/I, Pascal, Basic, etc.) should be expressible with these 
commands. In formulating an Interactive query, the user should 
have the option of typing In the necessary commands or choosing 
from a "menu" of commands he may execute. The user and the 
ilAALll. g££ll£JAjLlj&il £££g£^gg JBiilAll ILfil kA LAAHILAA kiL&M. liU 
££££l£JSt £il£JEll£Al ££ l££aiAljlJ AX lilt iglJl 

eased. Rather, data Items shall be ref erenceable by 
^specifying only the logical name assigned to that data item, 
with ADAM responsible for physically finding and accessing the 
referenced Items. 

3.H EXTENSIVE AND INTEGRATED INFORMATION ABOUT DATA 

Scientific users generally require access to the "pedigree" of 
data in a data base: who collected It, when, where, with what 

Instrument, and how It has been processed. Hays to search, 
scan, and select this Information electronically are needed to 
help the user find data relevant to his application [DJRD 79, 
LHMN 80A, FJMT 81]. In addition, the data, manager and 
application programmers need to know how system programs, data, 
and Users are inter-related In order to assess the Impact of 
changes to any of these system entitles. 

Extensive capabilities shall therefore be Integrated Into the 
ADAM to store and maintain In machlne-prooessable form 
Information about data In the data base, whether or not that 
data Is Itself accessible through ADAM (e.g., non-digltal data* 
products). These capabilities shall comprise a Data Dictionary 
that provides documentation In machlne-prooessable form 
pertaining to each program or module which accesses the data 
base, and to each data Item or element -- the smallest data unit 
In the data base that can be accessed. The data dictionary 
should itself be an integrated data base that Is managed by the 
ADAM (see, for example [JHNS 80]). Entries for data items must 
contain all Information about each Item that Is relevant to Its 
use: Its origin, spatial and temporal extent and resolution, 

how It was collected and processed, what programs use It, and 
what It means In physical terms [GARY 80]. Similar attributes 
shall be stored for each program or module of a data system, and 
potentially for each user. Finally, aggregations of these 
Items, such as an entire file or data set, should have entries 
In the Data Dictionary that describe their characteristics and 
constituents. For details, see Function 1.^ of Appendix A. 
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3.5 LAMGUAGES FDJ JEFlllIliG DATA STRUCTURES AND FORMATS 


Users should not have to oonoern themselves with the details of 
data formats, device protocols, etc. Users' application programs 
should not be Impacted by changes to the physical arrangement of 
the data that they access or by changes to the storage devices 
on which that data resides. 

Data managers and some, users need to describe to the system the 
logical data structure, the user-specific formats, the physical 
data structure, and the actual layout on a particular storage 
device. Separate specification of these four aspects, three of 
which are outlined In the widely accepted ANSI/SPARC Conceptual 
Framework [URNA 81B], ensures the data Independence required by 
users (see also Section 2). 

The ADAM must therefore have commands that enable a data manager 
or knowledgeable user to define these four distinct aspects of 
each file In the data base. Each aspect requires a simple, 
high-level language that Is suited to the definition of the 
appropriate parameters. The languages are: 

o ItAlA IJ2J1L1 to specify the logical 

format, or "schema", of the data base, which gives the 
organization of the data base; data Item names, types, 
and sizes, etc. This capability must be far more robust 
than the standard FORTRAN data definition capability. 

o iLa££ llAM. £££lJll£li2Jl L&IkS.ilIL&Si to describe 

user-specific subsets of the data base, renaming of data 
Items, and other format differences from the global 
logical format ("user views") that are easier for users 
or users' application programs to understand. 

establish the physical arrangement of data in a way that 
Is Independent of the device on which It Is stored but 
permits enforcing physical contiguity of related data. 

0 IlULalDAl PgYiQg £rP,t.P.g.9i Language 

to detail the parameters peculiar to the actual 
<<evlce(s) on which the data may reside In order to 
optimize storage and retrieval of that data. 

Ideally, the user should be able to have as many layers of 
schemata as are necessary to achieve data independence, and the 
various definition languages should share common constructs 
wherever possible for simplicity [JHNS 80]. For detailed 
specifications on these languages, see Function 1 of Appendix A. 
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3.6 SCIENTIFIC DATA 112.KS AMD STRUCTURES 

Solentlflo data la numerioally-orlentod^ and often la generated 
In binary form by aenaora. Uaera need to at ore Imagea, 
ancillary deaorlptlve Information, Iji situ obaervatlona, ayatem 
flaga, reaulta of oalculatlona, vectors, arrays, and many other 
varied types of data Items [APNY 81, ECSY 79i ERTH 76, LOTS 79B, 
ODBA 79]. 

The ADAM shall therefore be required to define, store, retrieve, 
and update efficiently at leaat the following atomic data types: 

o Fixed point binary numbers, including "double precision". 


0 Floating point numbers stored efficiently in scientific 
notation, i.e., signed mantissa and exponent, not as a 
character string. 


o Alphanumeric (or "character") strings, including 
variable-length strings possibly of great length (e.g., 
paragraphs of explanatory text). 


o Bit strings, which efficiently store binary data in a form 
that permits access at the bit level. 

0 Boolean or logical variables that indicate "true" or 
"false" conditions. 


These data types may be 
Ideally, the ADAM should 
optional listing of valid 
values = MONDAY, TUESDAY 


either constants or named variables, 
permit user-defined data types with 
values (e.g., data type r DAY OF WEEK, 
, ..., SUNDAY). 


The user or data manager must be able to define data structures 
(using the languages described in Section 3*5) that aggregate 
these atomic data types into multi-dimensional arrays 
(matrices), hierarchical structures, and/or records. These 
structures may be of either fixed or variable length. No limit 
should be placed on the maximum size of any logical constructs, 
such as fields, records, or files. For example, limiting the 
maximum length of a field to 255 characters is unacceptable. To 
illustrate, a single image in raster format is stored as a 2- 
dlmenslonal array that may well exceed 1 megabyte (1024 x 1024 
picture elements), plus header and ancillary information [BLSR 
80 ]. 

3.7 FLEXIBLE Piiy^lCAL ACCESS MECHANISMS 

NASA/OSTA data bases contain highly inter-related data and 
unstructured data such as text strings, both of which must be 
efficiently searched. In addition, the rates at which records 
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are updated, added, deleted, and queried will differ depending 
upon the application [APNY 61]. 

Therefore, the ADAH ahould support several physical access 
mechanisms that may be selected by the data base designer 
through the Physical Storage Organization Definition Language 
(see Section 3*5). These access mechanism options should 
Include any combination of: (1) indexes using a variety of B- 

trees or other easily balanced tree, (2) calculated derivation 
of a key by either generalized hashing or by an application- 
specific program (e.g., using satellite ephemerls data to 
convert latitude and longitude to time of overflight), and (3) 
efficient text pattern searching. 

Users should be able to define keys composed of concatenated 
logical fields. For example, the key field TIME could, be 
defined to ba a concatenation of Individual fields called YEAR, 
JULIAN-DAY, HOUR, MINUTE, and SECOND. 

3.6 &2M1AL 

A common thread linking all NASA/OSTA data bases Is the spatial 
orientation of the data. In virtually all applications, users 
must be able to locate observations relative to some subset of 
space and time. Most commonly, especially for Images, this 
takes the form of the two-dimensional (locally flattened) 
surface of the earth, often keyed by latitude and longitude. 
However, global data sets, and oceanographic and atmospheric 
data, must be represented In 3-space, plus time [APNY 61]. Data 
management systems that structure data primarily to represent 
spatial relationships (e.g., distance, contiguity or 
connectedness, overlap, etc.) and to key upon spatial location 
are often called Geographic Information Systems. Existing ones 
tend to be highly specialized towards a particular application, 
e.g., resource assessment using Landsat imagery [BRYN 76, MRBL 
77, NAGY 79, CHCK 61]. However, preserving spatial 
relationships is also Important to data bases containing data 
other than geographic Information, most notably engineering data 
for computer-aided design and computer-aided manufacturing 
(CAD/CAM) [DUBE 60]. 

The ADAM System must be able to support Geographic Information 
Systems applications by providing data structures that 
facilitate the representation of spatial relationships, time, 
and other dimensions of the data. Spatially oriented data to be 
stored by ADAM may be represented in any combination of raster 
format (i.e.,< a matrix of picture elements to be scanned in row- 
major order) or in vector-graphic form (e.g., points, lines, and 
polygons represented a s v a r 1 a b 1 e- 1 e ng t h lists of (x, y,) 
coordinates) [BRYN 76, DUBE 60]. These structures and the query 
capabilities of ADAM should permit the efficient retrieval of 
data related by at least the following relationships: 
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(1) Distance ; Ml data within a certain radial distance of a 
given location. 

(2) Pi r e c t i o n ; Data in a certain direction froa a given 
location, e.g.f "east of”. 

(3) Connectedness ; Whether lines form a single closed region, 
and if so, the associated attributes of that region such 
as area enclosed. 

(4) Overlap ; Whether two Intervals or regions overlap, and if 
so, by how much. High-level constructs in the query 
language should facilitate queries such as; "Retrieve all 
data blocks whose range of times intersects the Interval 
(t. tp)"; the user should not have to specify such 
rel4 tlonshlps in complex Boolean combinations using the 
standard ”<" and ">” relational operators commonly 
available in existing DBMS. 

At present, these relationships are not easily representable in 
any known DBMS. 

3.9 UmSlLAfiE LQl fiFFICIEHJLY MNlfflUmfi UlA 

Users need to load, store, change, find, access and/or display 
the data in the data base for their specific application. These 
data mnnipulatlon functions are found in one form or another in 
virtually all data management systems [APNY 81]. Users need to 
be able to access data readily, without significant programming 
effort. Simple queries should be easy to pose and quick to 
satisfy, but more complicated queries by knowledgeable users 
must also be possible. Users unfamiliar with the system should 
be guided through a set of menus, whereas accomplished users 
should have the option of bypassing the menu through a command 
language. 

Thus, ADAM must permit the user to manipulate data readily, 
either Item-by-ltem or masse , using a simple, high-level non- 
procedural language that is easy for scientific users to 
understand and use (see Section 3.3). The ADAM System shall have 
an Interactive query processor that performs the same basic 
operations performed by the data manipulation language. The 
user should be able to store, retrieve, and edit sets of query 
commands, and Ideally should be able to "program" in this 
language by defining variables, expressions, branching, etc. 
Queries upon non-keyed as well as keyed fields should be 
possible, and data base access should be automatically optimized 
accordingly. The query processor should Inform the user of the 
expected amount of data to be retrieved before significant 
retrieval is accomplished, and should allow the user to narrow 
his query by adding additional Boolean constraints. While 
retrieval of data is in progress, users should be able to 
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initiate other routines In parallel | determine the status of his 
query, and/or cancel further retrieval without losing the data 
retrieved to date. Ideally, the same high-level, non-procedure 
language will be used for both the Interactive query processor 
and the application program Interface, so that applications can 
be developed first Interactively and then migrate to application 
programs when It Is sufficiently well defined. 

The required functions are those provided by any existing 
commercial DBMS. They Include those to load the data base, to 
edit and Input new data, to find and access selected data, to 
rearrange or aggregate data Items, to modify the content of data 
Items, to delete unneeded data, and to display data. For a 
detailed specification of the required functions, the reader Is 
referred to Function 3 of Appendix A. 


3.10 DATA BASE 

Data managers need utilities for protecting and maintaining the 
data base for the users [APNT 81 J. The ADAM System must provide 
these utilities In a way that can remain transparent to the 
user. They Include the functions of data security, backup and 
recovery, ensuring data base quality and Integrity, the 
allocation and deallocation of storage space, monitoring and 
tuning system performance, providing estimates and accounting of 
system costs, and providing efficient but flexible Interfaces to 
system programs that Invoke or are invoked by the ADAM (see 
Function 2 of Appendix A for details). 

3.11 HIGH-RATE INPUT/OUTPUT STOBAGE 

Ear th-orbltlng satellites are returning ever larger amounts of 
data at alarming rates. It has been projected that yearly data 
volumes from earth resource observation satellites will increase 
from 10^3 to 10^^ bits per year by 1 995. The data rates of new 
Instruments will Increase from the 15 megabits per second for 
the current multi-spectral scanner Instrument, to 85 megabits 
per second for the Thematic Mapper, to rates of 200 to 400 
megabits per second for Multiple Linear Array and Synthetic 
Aperture Radar Instruments In the late 1980's [BRCK 80]. 
Present plans for the Thematic Mapper data call for processing 
and archiving approximately one hundred frames, each composed of 
6 spectral Images of over 2 x 10^ bits each, or over one 
terabit, per day [BLLN 81]. 

Therefore, ADAM must, with the appropriate enhancements, be 
capable of extracting any subset of a large (10^^ - 10'^ bytes) 
data base, by multiple keys. This should require a time 
proportional to the size of the output dats^ set rather than the 
size of the data base. Users must be given an estimate of the 
cost (In terms of disk accesses required) to perform any 
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significant data retrieval that is requested the 

retrieval is perforoed. The results of a query should itself be 
a data base that can be further queried. This is so that a user 
can iteratively narrow the search for relevant data by ANDing 
additional Boolean conditions with previous conditions without 
having to re-search the entire data base. 

The ADAM must be capable of loading data from the above 
Instruments into the data base, and establishing multiple-key 
relationships, fast enough to avoid backlog, while still 
allowing users sufficient time to access the data base. See 
Section 5 for more discussion of the ADAM performance 
requirements. 


Data which users require is currently distributed among many 
different data bases and files on differing computer types at 
various locations across the country [APNT 61, FJMT 61]. Some 
of these data bases are beginning to be networked together. In 
particular, the ADAM is Intended to be implemented in 
installations which Include the nodes of the proposed 
Applications Data Service network [OFNS 79, DJRD 79]. A 
possible configuration of such a nfrtwork is given in Figure 3-1, 
showing the heterogeneity of computer architectures and 
communication speeds as well as the replication of ADAM at 
certain nodes. 

With the appropriate enhancements, ADAM should be capable of 
operating as one node in a distributed heterogeneous data base 
network, and/or in a distributed processin g network. In the 
former, request commands for data in the data base of one 
installation may come to its ADAM from a remote user through his 
ADAM and an inter-computer network Joining the two installations 
[CHUW 79]. The latter type of network configuration permits the 
ADAM to reside on a processor different from the processor in 
which the user's application program is executing. The 
processors in which ADAMs are executing may thus be specialized 
"data base machines" that are optimally configured for 
performing their data management chores [SUSY 80]> 

3.13 .HELL £££1.G£EJ? SUPPORTED 

Inevitably the requirements which ADAM addresses will change and 
ADAM will have to be maintained and augmented [ZLKH 78, BOHM 
76 ]. The ADAM System software must, therefore, be maintainable 
and well supported throughout its llfeti. me by complete 
documentation, knowledgeable and available user consultants, 
development programmers, and system programmers capable of 
resolving ADAM "bugs" or anomalies. It must be a field-proven 
software package that is well-structured, modular, and uses 
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(HIGH-SPEED LOCAL NETWORK) 
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Figure 3“ 1» Example of Use of ADAM in a Distributed Hetwor 
Exhibiting Heterogeneous Processors and Coaaunication Link Speeds 










accepted software engineering principles. For aore dlsouaslon 
of these requirements^ see Sections 4 and 6. 


SECTION it 


IMPLEMENTATION CHARACTERISTICS 

"Nsither function alono nor alaplioity alona 
dafinea a good daslgn" 

.. Brooka 


Tha ADAM Systan should ba laplasantad in a particular way in 
order to naet certain user raquirasanta. Thaaa oharaotarietica 
are described in this section. 

it.1 FLEIIBLE Aim ADAmBliB 

As described in Section 1, ADAM is intended to ba a general- 
purpose tool that will be utilized by differing applications, 
many of which are research or developaent oriented [F<IMT 81]. 
Hence the ADAM must be adaptable to different applications as 
well as to requlreaents varying over tine for any given 
application (e.g., changing data aanageaent requlreaents for a 
flight project using ADAM). 

More specifically, ADAM should: 

(1) Permit the addition of functional capabilitias or data 
types (e.g., iaage data types) to a nucleus of basic 
functional capabilities and data types without requiring a 
complete system generation (see also Section J|.2), either 
as add-on modules of the ADAM or as user-supplied softwai's. 

.(2) Permit the Data Base Administrator to define new functions 
and data types without requiring the recompilation of 
existing commar^ds or schemata. 

t 

(3) Have all system parameters specified as variables with 
default values which may be altered by the Data Base 
Administrator . 

(A) Allow the Data Base Administrator (or users, where 
authorized by the DBA) to make changes to: data item sizes 

for storage or display, search key designations, data 
structures, formats, storage media locations. Indexes, data 
dictionary entries, integrity constraints, security 
authorizations, and any other specifications. This should 
be done in a way that is simple to accomplish^ has minimal 
impact on other ADAM components, and requires minimal human 
and computer resources. 

(5) able to map user-defined variables in a user view (or 

’’subschema") to the global logical structure (schema) in a 


J |-1 


dynaaio way; for txaaplaf without raquiring aodlfioation or 
raooapllatlon of an application prograa whanevar tha aohaaa 
ohangaa tha oharaotariatioa of data itaas not uoad by that 
prograa. 


Moat of thaaa ohangaa should ba abla to ba aada dynaaioally 
whila tha ayataa is running. 


glfAIPABLg 


Not all uaara will raquira tha full ooaplaaant of ADAM 
oapabilitiaa that aoaa uaara will raquira -- tha raquiraaants 
and hardwara raaouroaa of diffarant projaota vary oonaidarably 
CFJMT 81]. Tharaforty it should ba posslbla to augaent the 
nucleus of ADAH with additional capabilities required by a 
particular user. For axaapla, sophistloatad graphics and/or 
report writing oapabllltlas are not required by all users, and 
can add oonsidarabla overhead to ADAM (in the fora of maaory 
required to execute) even if they are not used. Addition of 
these optional capabilities, either as aodules of tha ADAM or as 
user-supplied routines, should be easy for the Data Base 
Adainis tra tor to lapleaent and should not require systea 
regeneration. 

IQfrgQIM. AICH1II6IP8E 

The requireaent of Section 4.2 laplles the need for a top-down, 
aodular software architecture with standardized Interfaces 
between aodules, as is illustrated in Appendix A. Modules 
should be organized along functional lines with the goal of 
alnlaizlng the lapaot that any changes to a aodule might have to 
related aodules. 

laiMSPQBTABLE 


The ADAH System must be transportable between different 
coaputers and different operating systeas to the maximum extent 
possible. The ADAM will be implemented on many different 
coaputers, including potentially those of Digital Equipment 
Corporation, IBM, and Unlvac. These machines may be either 
alniooaputers or large mainframes, and may vary in their word 
size, machine language, internal representations, etc. Similar 
machines may operate under different operating systems. Any one 
given computer may upgrade or change operating systems over 
time. New versions of computer hardware and operating systems 
are inevitable. Therefore, this need for a transportable design 
of the ADAM software Is a stronger requirement than one which 
specifies the particular machines to which ADAM must be adapted. 


To achieve transportability, ADAM should: 


(1) be written largely in a high-level language; 


(2) oonotntrit* all intcrfaoas Hith tha oparafcing ayataa, and 
all uaa of aaohlna language ooasiandsi to a anall set of 
well-doouaented Bodules. This nequlreaent reinforces the 
requlreaerit of Section 4.3 for aodular software design; 

(3) not require any aodlf ica tions (other than tuning) to the 
host operating 8yste>; and 

(4) have no globally reserved '4;eywordB. 

See [ALLC 80A| ALLC 608] for an exaaple of an existing file 
access systea that is based upon these principles and is 
iapleaented in the Pascal language. Another strategy, using a 
very high level "aacro" language that can be processed into 
systea-specif io FORTRAN coaaands is described in [SCNC 80]. 

4.8 IHTiRrACEABLS 

The ADAM should have interfaces that are siaple, concentrated in 
a alnlaal set of aodules, and transparent to the user. 
Interfaces to the following software systems is a alniaal 
requlreaent : 

(1) Operating Systea. As described in the requlreaent of 
Section 4.4p the ADAM interface with the aaohlne's 
operating system should be concentrated into a small set 
of modules that can be customized as needed for different 
computers and/or different operating systems. See 
Function 4.2 in Appendix A for details. 

(2) Language Compilers. Programs written in FORTRAN and 
machine language shall be callable from the ADAM. 
Conversely, ADAM functions shall be invokable from 
application programs written in these languages, either by 
utilizing CALLS to ADAM and passing functions and their 
operands as parameters, by interpreting ADAM commands into 
the host language with a pre-processor, or using any other 
efficient technique. Interfaces to other programming 
languages, such as PL/1 and Pascal, are highly desirable 
due to their commands that are high-level, Engllsh-llke, 
and consistent with structured programming principles 
[ANDR 80]. 

(3) VICAR. As part of the image-handling augmentation to the 
ADAM, there shall be an interface to the Video Image 
Communication And Retrieval (VICAR) system that was 
developed by the Jet Propulsion Laboratory [SDMN T9] ond 
is available in the open domain through COSMIC at the 
University of Georgia. 



(k) TAE. Optionally, ADAM should be able to interface with 
the Transportable Applications Executive developed by the 
Goddard Space Flight Center, To see how this is being 
done with one DBMS, see [BCHM 61]. 
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PERFORMANCE 


As stated in Section 3t absolute perfopmanoe specifications are 
dependent upon the data base characteristics and the user 
requirements for a given application. It la therefore 
impossible to define quantifiable, absolute requirements upon a 
general-purpose package such as the ADAM. Furthermore, 
NASA/OSTA experience with this technology is still quite 
limited. Experience with prototype applications on the 
Applications Data Service pilot systems at Goddard Space Flight 
Center, Johnson Space Center, and Jet Propulsion Laboratory 
within the next year should help to focus DBMS performance 
requirements. At a minimum, ADAM shall be required to perform 
in benchmark tests at least as well as the DBMSs used by these 
pilot systems, as well as that used by the DBMS-based JPL Mark 
IV Data Records System, and better than an identical application 
implemented using a generalized file management system. 


Performance superior to the basic requirements of this section 
is highly desirable and should be weighted heavily in any 
evaluation of compliance with these requirements. 

A brief description of each of the major categories of DBMS 
performance requirements follows. Some of the following 
requirements are more important than others. For example, it is 
anticipated that in most NASA/OSTA applications, large volumes 
of new data will be loaded into the data base and periodically 
retrieved, with relatively little updating of the data base. 
Therefore, Requirement 5.2 is secondary to Requirements 5.1 and 
5.3. 

5 . 1 MA-S^ MIA R ECEIPT AM LOAD 

The development of sensors which generate data at rates ranging 
from 85 to 1<00 megabits per second (Mbps) is predicted by 
NASA/OSTA for the decade in which the ADAM should be operational 
[BRCK 80]. Applications in which multiple users are 
simultaneously retrieving images -- each image composed of the 
order of millions of bytes -- from the data base will pose 
similar requirements. Already the NASA End-to-End Data System 
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(NEEDS) Project is developing an archival mass storage device 
which is capable of accepting data at the rate of 100 Mbpa 
(albeit qualified by a 20% duty cycle) [THMS 80]. Therefore, 
the ADAM must for some applications be capable of being 
augmented or enhanced In such a way that it can accept and load 
data Into the data base and maintain the needed multiple keys at 
these rates, given the machine cycle times and input /output 
rates expected from hardware technology advances foj? the same 
period. Furthermore, it is likely that cost-effective random- 
access storage for these large volumes of data, most notably 
digital optical disc media that unfortunately are currently 
wrlte-once, will not be commercially available for several years 
(SBSO 80]. Hence, access to some portions of any data base may 
require the unloading and re-loading of data from a magnetic 
tape archive to the data base on magnetic disk on a routine 
basis. This near-term eventuality further underscores the need 
for efficient loading by ADAM. 

5.2 SELECTED DATA STORE/ UPDATE 

The ADAM overhead which is used to facilitate the location and 
retrieval of data from the data base shs,ll not place undue 
burden upon functions which update or Insert new data into the 
data base. For example, the maintenance of Inverted lists for 
many keys needed by users, as la done by Intel's System 2000/80 
can significantly Increase both the time needed to alter the 
data base and the space consumed by the Inverted lists. 
However, analysis of existing NASA/OSXA and related data 
management systems suggests that volatility of these and future 
data bases is likely to be quite low In ADAM environments other 
than algorithm development facilities (see Section 1.3). 

5.3 SELECTED MIA RETRIEVAL MU DISPLAY 

User requirements for data delivery from the processing center 
to data distribution centers have been projected to Increase 
from the order of days in the 1980s to the order of hours or 
minutes In the 1990s [BRCK 80]. In the anticipated environments 
of the ADAM, where the user will be directly interacting with 
the data base, retrieval and display of selected data will have 
to be accomplished within seconds to retain an effective 
interactive user Interface that is conducive to scientific 
inquiry. Interactive users are unwilling to wait minutes or 
hours for a few lines of data or an Image, and usually assume a 
system failure has occurred if they are not warned every 5 to 10 
seconds during long operations. Therefore, the ADAM must be 
capable of retrieving and displaying data expeditiously. 
Including images comprising tens of millions of bits. 
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5.4 


C01I.CURBEHT JLSJS 


The ADAM SysteiD shall be capable of concurrent use by at least 8 
to 16 users without significant degradation of system response 
time. A user should be able to execute non-ADAM tasks and 
lengthy ADAM operations in parallel. 

5.5 DATA ^jSE REORGANIZE/REDEFIME 

Respeclf lea tlon by the Data Base Admlnls trat’or (DBA) of the 
global logical structure or either component of the physical 
data structure may result In ADAM having to reorganize the data 
base, either to retain data base consistency with the new 
definitions or to re-optlmlze system performance. Actual 
reorganization of the data base shall be under the control of 
the DBA, Including an option that will permit the .DBA to defer 
portions of the reorganization, and shall have minimal impact on 
system operability. 

5.6 RELIABILITY 

The impact of ADAM and/or system failures upon the Integrity 
and/or operability of the data base shall be minimized through 
the efficient implementation of Function 2.2 (Backup and 
Recovery), and by satisfying the support requirements of Section 
6 throughout the lifetime of the ADAM. ADAM errors that require 
re-creation of an entire data base must be more rare than errors 
that effect a single retrieval. 
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SECTION 6 


SUPPORT 

"Documentation Is the castor oil of programming... 
the managers know It must be good because 
programmers hate It so much." 

-- Weinberg 


The NASA/OSTA requirements for data base management will 
continue to evolve over time after the Initial development of 
the ADAM, due to changing computer technology, sensor 
technology, mission objectives, and user requirements [BRCK 80]. 
Therefore, It Is Imperative that ADAM be fully supported by a 
viable, on-going organization which can aid the Implementation 
and augmentation of ADAM for new applications. 

6.1 FJILLY SUPJQRTED SOFTWARE 

The ADAM shall consist of software which Is guaranteed to be 
supported by the developing brgaqlzatlon for not less than ten 
years. This support shall Include (but not be limited to): 

o Thorough documentation, to Include at least a system design 
document, a user’s manual, a system reference 
manual/programmer's guide, a management executive summary, 
complete Internal documentation of all 'code, a DBA 
guide/tuning guide, an Installation guide for each operating 
system, and an operator's diagnostic manual. Such 
documentation shall meet or exceed the JPL internal software 
standard practices requirements [JPLS 80]. 

o User consultants who are Intimately familiar with every 
aspect of the system's design, structure, limitations, known 
problems or workarounds, operation, commands, and debugging. 

o System programmers who are capable of diagnosing and 
correcting system failures within a short period of time (on 
the order of hours, not days). 

o Development programmers who are capable of designing, 
developing, debugging, testing, and evaluating qeeded 
enhancements to the ADAM, as determined Jointly by NASA/OSTA 
and the supporting organization. 

6.2 NEW NASA COMPUTER TXPES 

Support of ADAM shall Include adapting the system to new 
computers upon which NASA/OSTA wishes to implement the ADAM, 
including new models or other computers not now in existence, as 
mutually agreed upon by NASA/OSTA and the supporting 
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organization. Satisfaction of this requires ent should be 
facilitated by the Implementation Characteristics Requirements 
4.1 (Flexible and Adaptable), 4.3 (Top-Down, Nodular 
Architecture), and especially 4.4 (Transportable). 

6.3 RlMSl SJUIIQM XQ MAJ.QJ NISSIQlfS 

In addition to the standard support described in Support 
Requirement 6.1, certain major future missions may require 
supplemental support to meet mission-specific schedules, user 
requirements, operational readiness, or other requirements. 
This may Include the need for on-site and/or round-the-clock 
availability of support personnel, as determined by NASA/OSTA. 


6-2 



[ALLC 80A] 


SECTION 7 
REFERENCES 


[ALLC 80B] 

[ANDR 80] 
[APNY 813 

[BCHM 81 ] 

[BLCK. 80] 
[BLLN 81] 
[BLSR 80] 

[BOHM 76] 
[BRCK 80] 


Allohln,J. E., "FLASH: A Language- 

Independent, Portable File Aooeaa Syatea", 

Conf.9Ls.DQs nn Miami tat aX aiiai chen, Peter p. 
and Sprowle, R. Clay, editors, ACM Order No. 
JI72800, ACM, New York, 1980. 

Allchin, Janes E., "FLASH: A Language 

Independent, Portable File Access Systen, User's 
Guide", Internal Docuaent, Stanford University, 
Stanford, CA, I960. 

Anderson, Barbara V., Jet Propulsion Laboratory, 
Pasadena, CA, Personal Comnunloa tlon, 26 August 
1 9 80 . 

A pe ny o , Kofi, Survey of Representative Database 
JPL Internal Meaorandun (under 
preparation). Jet Propulsion Laboratory, 
Pasadena, CA. 

Bachman, P. W., Heifer, D. P., and Herath, L. H. , 
"Functional Interface Agreement: TAE, AOS, and 

PCDBMS Projects", Goddard Space Flight Center, 
Greenbelt, MD, May 1981. 

Blackwell, Richard J., Jet Propulsion Laboratory, 
Pasadena, CA, Personal Communication, 27 October 
1980 . 

i 

Billingsley, Fred C,, Jet Propulsion Laboratory, 
Pasadena, CA, Personal Communication, 3 September 
1981. 

Blaser, A. (ed.), SlnlA XAH 

Pictorial Applications . Florence, Italy, 20-22 
June 1979» Lecture Notes in Computer Science, 
Vol. 81, Goos, G. and Hartmanls, J. (eds.), 
Springer-Verlag, New York, 1980. 

Boehm, Barry w., "Software Engineering", IEEE 
XcailsaaJlXajia nn £±£1* 12 (December 

1976), pp. 1226-12H1. 

Bracken, Peter A., "Earth Observation Data 
Systems in the 1 980's, Proc. jelI the 1 Q 80 Annual 


7 - 1 


[BRDK 80] 
[BRNS 80] 

[BRWN 80] 
[BRYN 76] 

[BRYN 79A] 
[BRYN 79B] 

[BURN 80] 

[CDSY 71] 
[CHCK 81] 

[CHUN 79] 


SLS. ilLi AMA£1£AJ1 i 

Boston, MA, 20-23 Oot. I960. 

Bredeksap, J., "NASA Oats Base Systems (as of 
1978)”, Personal Conaunloatlon, 2 April 1980. 

Bernstein, Ralph (Chairman), Data M anagement jblDjI 
Computation: Issues ind AJLCilBBAMBllfiJLBa. PrBf.t 

7 . Committee Data Management jlM Computation. 
Ababa AbIABB a ABABA » National Academy of 
Soiencer, Washington, DC, September 1980. 

Brown, James, Jet Propulsion Laboratory, 
Pasadena, CA, Personal Communication, 22 October 
1 9 80 . 

Bryant, Nevin A. and Zobrlst, Albert L., "IBIS: 
A geographic information system based on digital 
image processing and image raster datatype”. 
M achine Processing 2I AABBIaIA AAJQAAA AaI&i IEEE, 
1976, PP. 1A-1 to 1A-7; also, lAAA XCABAABllBBA 
BB Geo science AlABiBBBlBBt Vol. GE-15, No. 3 
(July 1977)» PP» 152-159. 

Bryant, Nevin, BaIa Base Management Syste ms Panel 
Workshop: Executive Summary . JPL Publication 79 - 
70 , Jet Propulsion Laboratory, Pasadena, CA, 1 
August 1979* 

Bryant, Nevin, £1 ba1 AbBBBB bIL*. ABA ABBBBBIIBA 
Research Data Base AaBAAAAABB AYBiLABB f.SBBl 

W orkshop , Internal Document, Jet Propulsion 
Laboratory, Pasadena, CA, December 1979. 

Burns, Thomas E., The Mitre Corporation, McLean, 
VA, Presentation and Personal Communication, 10 
November 1980. 

CODASYL Systems Committee, Data Base Task Group 
Report, ACM, New York, April 1971. 

Chock, Margaret, Cardenas, Alfonso F., and 
Klinger, Allen, "Manipulating Data Structures in 
Pictorial Information Systems”, working paper (to 
appear in Nov. 1981 Comp uter ) , Computer Science 
Department, UCLA, Los Angeles, CA, June 1981. 

Chu, Wesley W. and Chen, Peter P., iJilBUiAii 

£ejttlr,AllzBA abA BIaBbIBbIaA BaIa Baab B^A^BJBlAt 

IEEE Catalog No. EH0154-5, IEEE, Long Beach, CA, 
October 1979. 


7-2 


[CRDN 79] 
[DATE 773 

CDJRD 793 

[DUBE 60] 
[ECSY 793 

[EDO 793 

[ERTH 76] 
[FJMT 813 

[FONG 803 
[GARY 80] 
[GDNU 793 


Cardenaa, Alfonao F., 

Syatama f Allyn and Baoon, Boston, 1979* 

Date, c. j*. An Xn.trAdufl.tiQJi la D,a.l}.ibft.a.a .Sjulaui 
Second edition, Addlaon Nealey, Reading, MA, 
1977. 

DesJardins, Richard (ed.), Si&ll iUlA JSjUlAJBa 
ZlAJULLna Mfirlalaa lanaiil ££jl£1 Z, ads study 
Office, Goddard Space Flight Center, Greenbelt, 
MD, 20 November 1979* 

Dube, Peter R., Al* » "An Approach for 

Management of Geometry Data”, Internal Document, 
Boeing Computer Services Co., Seattle, WA, I960. 

laaropdiujB siX StSlk Ildasla £a1a haajls. iDlorMatiajL* 
AapA Xt, AnjULQillx AiS ; lilaaAana=±aLajiaai:a:^£lJlA 
JEJuPAHJlla f Ecosystems International Inc., 
Gambrills, MD, under contract NAS5-25503 for 
Goddard Space Flight Center, November 1979* 

EROS Data Center (USGS), LANDSAT-D User CCT Tape 
£.&LIkAi.t NASA/EDC Report FOR-LSD-OO 1 A , EROS Data 
Center, U.S. Geological Survey, Sioux Falls, SD, 
August, 1979. 

Aarlll Z&SkA&LAf NASA Office of 

Applications (prepared by Systematica General 
Corporation, McLean, VA), 25 May 1976. 

Fujlmoto, Brad, i2^££ A£nilAi:£AAJllA X££ JKA^A XaXa 
£A££ H£J1£££A£J1A £xaA£A£j. ££XA 1± i2£££Jl£££££ilA£ 
DlsoiDllne , JpL Publication 81-50, Jet Propulsion 
Laboratory, Pasadena, CA, 15 June 1981. 

Fong, Elizabeth and Kimbleton, Stephen R., 
"Database Semantic Integrity for a Network Data 
Manager", £jl£££££lJlA£ £X A££ IMP ii£lA£JQ£l 
ZSLmAAit&L il£JlX£X£n££f 19-22 May 1980, Anaheim, 
CA, AFIPS Press, Arlington, VA, pp. 261-268. 

Gary, • J. Patrick, £l al.. MZA XaXa 

£££A£A Ui££££l XaXA £A££ 11£J1£££A£J1A £££l£A 
Functiona l Reoulre m ents , Information Extraction 
Division, Goddard Space Flight Center, Greenbelt, 
MD, March 1980. 

Goodenough, D.G., £X al. . "Standard Format for 
the Transfer of Geoooded Information in Spatial 
Data Polygon Files", Canada Centre for Remote 
Sensing, Ottawa, Canada, July 1979* 


7-3 


[GOUG 81] 


[GRNB 81] 


[JHNS 80] 


CJPLS 80 ] 


[KUCH 81] 


[LHMN 80A] 


[LHMN SOB] 


CLOTS 79A] 


[LOTS 79B] 


Gough, T.L., MX HmXA IJIAA HAJIA£11AJU 

Ani^yalB juul f-trlorijiiifij Toating jiliJi Hoopoot 

NASA RoQulrP B opt s f GSFC Doouadht No. BTS-FR-81- 
184, Contract No. NAS528561, Goddard Spaoa Flight 
Center, Greenbelt, MD, to appear. 

Greenberg, Ed and Hooke, Adrian, "Standard 
Hesaage Foraattlng Protocol for Spaceflight 
Appllcatlona", Draft 3, Internal Docunent, Jet 
Propulsion Laboratory, Pasadena, CA, 6 July 1981. 

Johnson, H.R., Comfort, D. L. , and Shull, D. D., 
"An Engineering Data Management System for IPAD", 
Internal Document, Boeing Computer Services Co., 
Seattle, WA, I98O. 

Jet Propulsion Laboratory, JPL Software Standard 

frafi.ti.sai Iaaiaafin.titAgn mxlX ManaKfiaaiLt Ml i£L 

&MllMMJlMt Draft, JPL Internal Document 500*152, 
Jet Propulsion Laboratory, Pasadena, CA, 25 June 
1980. 

Kuoh, T. and Sakamoto, R,, Survey of Federal . 
N,atlfi.nai> MMA international Standardfl AJPUfiabIfi 
XM lh£ JLAIA AMMllMMllMUM RmXM NASA 

Contractor Report 166675| The Mitre Corp«, 
McLean, VA, March 1981. 

Lehman, Guy M. and Renfrew, J. Thomas, A Proposed 

IML A ££UAXa 1 JlAJlAmlMA lAlMLMMllMJl 
Management Network . JPL Publication 79**111» Jat 
Propulsion Laboratory, Pasadena, CA, 15 January 
19 80. 

t 

Lohman, Guy M. (ed.), .S&&QI14L PaPfll HjELCiuJbllfif 

Monterey, CA, 14*16 January 1980, JPL Publication 
No. 80-50, Jet Propulsion Laboratory, Pasadena, 
CA, 1 November 198O. 

Loats, Harry L, Jr., je_t Applications Data 

JlAMJl AMMMlLMMMnXM &XuAXa. ElJlAl AMMMLX, 
Ecosystems International, Inc., Gambrllls, MD, 
November 1979. 

Loats, Harry L. Jr., mX IMBMMMAImM Ml QUA 

QMAM.& IaXA SIMAAS. IaLMLMAXImA^ IfiilLAjfil Xl 

Q1LAM.XML2L Ml &AAAMIU lAAASlL LLMIAMXA AAA 

Characteristics . Ecosystems International, Inc., 
Gambrllls, MD, under contract NAS5-25503 for 
Goddard Space Flight Center, November 1979* 


7-4 



[MRBL 77] 

[MRTN 76] 
[NAGY 79] 
[QAOC 79] 

[ODBA 79] 

CORNS 79] 

[SBSQ 80] 

[SCNC 80] 
[SDMN 79] 

[STNB 81] 
tSUSY 80] 


Marblet Duane F, and Peuquet, Donna J.» "Conputer 
Software for Spatial Data Handling: Current 

Statue and Future Developnent Needs**, working 
paper, Geographic Infornation SydteBa Laboratory, 
State University of New York at Buffalo, Buffalo, 
NY, 1977. 

Martin, Janes, £rlA£isillAJl 

Manaaenent f Prentice-Hall, Englewood Cliffs, NJ, 

1976. 

Nagy, George and Nagle, Shared G., **Geographic 
Data Processing**, Con nut ina Surveys JLl, 2 (June 
1979), PP. 139-181. 

OAO Corporation, JIaaj: lAfliLlHAAAlliA £A£ JIA£A 
Climate Data Base Management Svaten . prepared for 
Goddard Space Flight Center, Greenbelt, MD, under 
contract NAS5-23436 Mod. 27, OAO Corp., 
Beltsville, MD, 1 October 1979. 

Office of the Data Base Adninlstr ator , Scientific 
and Technical. Snatlal,. and Blitllcgr anhic J2 a1jI 
AX iLi£jL &U£JLft£, Geological 

Survey Circular 817, U.S.G.S., Reston, VA, 

October 1979. 

Ofenstein, W. Thomas, JlLlx RfljQUir.gBPILfcg XA£ JLB 
RaIM AAXIaISLL £, The 

Analytic Sciences Corp., Reading, MA, under 
contract NAS5-25739 for Goddard Space Flight 
Center, 19 December 1979. 

Strategic Business Services, XJBJUgiilX aX On tlcal 

h£msrlsA (VAdft9iU.8,0A). aa SjmsjiAar. ajiA Imaaa 
LLSLAAAAIae IaAAAIlIaa, strategic Business 
Services, San Jose, CA, May 1980. 

S cience f "At Last There Is a Way to Take It with 
You", Science . Vol. 207, 15 February I 98 O. 

# 

Seldman, J. B. and Smith, A. Y., YICAB iMASA 
IXAAAAAlLA jSXSXAA IdAljlfi As £XA1AM ILOAI, JPL 
Publication Vf-Slt Revision 1, Jet Propulsion 
Laboratory, Pasadena, CA, 1 December 1979. 

Stonebraker, Michael, "Operating System Support 
for Database Management", CACM 2JLi 7 (July 1981), 
pp. 1112-^118. 

Su, Stanley Y. V., e t al. . "Database Machines and 
Some Issues on DBMS Standards", Prop, of 1 Q80 


7-5 


CTHMS 80] 
tURNA 81A] 

[URNA 81B] 

[WLTN 80] 
[ZLKH 78] 


JUiiliw JUstHlU. (Vol, 4 9) » AFIPS Pr«oa, 

Arlington, VA, I960, pp. 191-208# 

Thonas, Doug, Marshall Space Flight Center, AL, 
Personal CosBunioatlon, August 1980. 

Urefla, Jose L. (ed.), JdAll MMA£ hAMMMJtMAJlJi 
£MHAla. IhJirjl MJi£XMhJ2Ji £UMMM£X, JPl 
Publloation 81-52, Jet Propulsion Laboratory, 
Pasadena, CA, 15 July 1961. 

Urena, Jose, ^ILCXfiJC Al JiJiA£dM£Jll ASi£Xl£lJllJt jLfi 
J2 jULA JBUBJK Manaaeaent Systems , JPL Publloation 81- 
66, Jet Propulsion Laboratory, P adena, CA, 1 
October I 98 I. 

Walton, Barbara, Goddard Space Flight Center, 
Greenbelt, MD, Personal Communication, September 
1980 . 

ZelKowltz,M. V., "Perspectives of Software 
Engineering", ££M£Mll££ £M£X£X£ lH, 2 (June 
1978), pp. 197-216. 


7-6 



APPENDIX A 


DETAILED FUNCTIONS REQUIRED 

"Conceptual integrity is the nost 
inportant consideration in systea design." 

Brooks 


This appendix describes in detail the functions that the ADAM must 
perform. Note that these functions are generlCf not applioa tlon-« 
specific, in keeping with the mul tl- m isslon objective of the ADAM. 
It is intended that missions will use the high-level functions 
provided by the ADAM as powerful building blocks for constructing 
individual data management systems that are tailored to specific 
applications, much as the commands of FORTRAN are now used as the 
general-purpose raw materials of many systems. 

The required functions are structured hierarchically in a top-down or 
successive reflndment manner (see Figure A-1 at the end of this 
Appendix). This was done to ensure consistency and completeness in 
the specification of what functions are required. Each function is 
expressed as a predicate, l.e., a verb-object pair. For any given 
function in the "tree" of Figure A-1, the functions on the next level 
of detail answer the question: "Hhat must be done to accomplish this 
function?" Each of the lower-level functions must be necessary to 
the completion of the higher-level function, and collectively they 
must be sufficient to accomplish it. Note, however, that it is not 
the Intent of this "top-down functional analysis" (TDFA) to specify 
hSlM. the ADAM accomplishes each function. Except for the 
implementation end performance requirements of Sections 4 and 5, how 
a function is accomplished is a design decision to be made by the 
developer of ADAM. 

The rest of this appendix is devoted to describing In some detail the 
required functions named In Figure A-1. Where appropriate, examples 
of their usage are also given. To get Just an overview of the 
functions, the reader can skip lower level functions, which are 
numbered with more qualifiers. The numbers assigned to functions 
have Afi relationship to the sections of the main document. 

The overall function of ADAM shall be to provide data from the data 
base to Interactive users or users' application programs and back to 
the data base. Application programs are application-specific 
programs which require data from, and/or provide data to, the data 
base(s) belonging to ADAM. They usually are written In a high-level 
programming language such as FORTRAN, PL/I, or Pascal, but could be 
sequences of ADAM commands. Examples of application programs Include 
programs to process raw data into engineering units or geophysical 
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paranetera, laage prooeaaing and enhancement routinea^ atatlatioal 
paokagea, laage oo-regiatnatlon aXgorithaa, or alaple uaer requeata 
to diaplay data (e.g.i an laage or a aubaet of obaerva tlona) or 
Inforaatlon about the data baae (e.g,, a catalog) on a teralnal or 
printer. Note that the tera ’’data” here Inoludea both obaervatlonaX 
data froa the data baae, aa well aa Inforaatlon about the data baae 
auoh aa oataXoga deaorlblng what data la available and Inforaatlon 
that aaalata the uae of the data baae (aee aXao Function 1.4), 

1. ^lMC.Tlf.R£ AMR £^TABLI^H PITA BASE 

The ADAM auat provide aeohanlaaa for apeclfylng atorage atruoturea 
Into which l;^oth obaervatlonaX data and Inforaatlon about the data 
baae aay be loaded, and for Initializing the data baae by efficiently 
reading data In arbitrary foraata Into the data baae jblQ a aaaa . in 
order to achieve data Independence (Capability Cl of Section 2.2), 
aeparate languagea ahall be provided to apeolfy the logical data baae 
atruoture, the uaer*a view (really the uaer^a orograa’a view) of that 
logical atructure, and the Dhv alcal layout of data on the ator ge 
devloea. These languagea are congruent with thoae apeolfled by the 
widely accepted ANSI/SPARC Conceptual Fraaework for DBMS [URNA 61B], 
For exaaple, the logical atructure (or "soheBa" in DBMS parlance) 
oontalna the user-oriented naaes of all data iteaa in the data baae, 
the user view (or "subscheaa") can specify a user-spenif io subset of 
these iteaa and renaae thea or reorder thea to fit his prograa, and 
the physical layout specifies the storage device and addresses for 
each item. 

1.1 miHE. Am MMEJL IUJIBAL I^OICAL structure (SCHEMA) 

The global logical atructure, or schema, describes In outline fora 
the characteristics of data items that are stored In the data base. 
Independent of its physical layout. The function and contents of the 
schema are similar to those of the DECLARE statement of PL/I. It la 
"global" In the sense that it encompasses all files In the data base 
and specifies a standard format for all users of each data base, 
regardless of how each user might view the data. 

The schema shall be specifiable by the Data Base Administrator (DBA) 
or by a knowledgeable, authorized user who generates a new file, 
using a language that has at least the functions of the 1978 CODASYL 
standard Data Definition Language (DDL) [URNA 81B]. Mechanisms for 
specifying, displaying, modifying, recompiling, and verifying the 
correctness of the schema shall be provided, either as part of the 
data dictionary (Function 1.4) or separately. 

1.1.1 The schema definition language shall assign a logical name to 
individual data Items or fields (Including those calculated from 
other data items); files; and any combination of other aggregates of 
data items. These other aggregates Include: sets (related records), 
Bul tl-dlmenslonal arrays (Including relations and Images represented 
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aa large 2-dlmenslonal arrays) posalbly having millions of entries, 
and hierarchical structures In outline form (like those of PL/I). 

1.1.2 The type and size of each data Item or data aggregate shall be 
specified In the schema. Data types shall Include Integer (In binary 
form), floating point, (l.e., scientific notation, stored efficiently 
aa signed mantissa and eicponent), character (text), byte, and logical 
(true/false). Special Internal representations shall be available to 
represent "not available" (or "not applicable") and "null", as 
distinguished from blanks and * os. 

Ideally, the user should be able to define new data types, optionally 
speclflylng explicit domains. For example, data type DAY-OF WEEK has 
the explicit domain (valid values) of MONDAY, TUESDAY, ..., SUNDAY. 
Also, the ADAM should be able to store values in an encoded form that 
may be more compact (e.g., MON, TUE, ..., SUN) and decode these back 
to more readable values for output. 

Data items and aggregates may be of fixed or variable length. Fixed- 
length Items may have a size declared for internal storage that 
differs from the size for display. Variable- length Items must be 
stored such that only the amount of non-blank data to be stored Is 
used, l.e., without padding. Repeating groups should be handled 
similarly, and permit an unknown number of Instances. 

1.1.3 The schema should have constructs which enable the DBA to 
specify integrity constraints upon each data Item. For example, a 
data item called SENSOR.MODE might be limited to having only values 
which correspond to legitimate sensor modes, say the integers 1 
through 100. The constraint types that are required are described 
In, and enforced by. Function 2.3. 

1.1.4, The schema shall also permit the establishment of logical 
relationships between the component data Items defined In Function 
1.1.1, such as the ordering of records within a file or of fields 
within a record, designation of fields to be keyed upon^ 
specification of set membership cr terla and "owning" records, stored 
tables of relations, pointers to r'?»ljtted data items, etc. 

1.1.5 The schema should have constructs which enable the DBA to 
specify security constraints upon data base entities such as files, 
programs, and users. These constraints should Include limitations 
upon and authorizations of the use of any ADAM function, at least at 
the file level and the data item level, as well as whether an 
authorized entity may grant that authorization to another entity. 
For example, ADAM should permit the DBA to authorize a principal 
Investigator to perform most functions on a file that was generated 
by his sensor and also to grant to selected colleagues, authorization 
to add to and access but not to modify data already In that file. 
In other cases, the DBA might wish to restrict all alterations 
(input, load, and modify) of only one data Item in a file -- perhaps 
a derived geophysical parameter -- to only the chairman of a change 


control board, while allowing read-only acceas 
unreatrloted acoeaa to the reat of the file. 


to that item and 


1 .2 2US£lil£,, MOfilflt Alt>a YBRIfy Um UM < SUBSCHEMA) 


The uaer view, or "aubacheaa'’ In DBMS parlance, dencrlbea in outline 
fora the oharacterlatlca of only the data iteoa and aggregatea needed 
by the prograa(a) of a particular uaer or group of uaera. Meohanlama 
for apeolfying, dlaplaylng, modifying, reconplling, and verifying the 
correctneaa of aubachemaa relative to the achema ahall be provided, 
either aa part of the data dictionary (Function 1.4) or aeparately. 


1.2.1 aubachema shall permit the user to select the aubaet of the 
data xtena from the achema that la needed, different names (e.g., 
shortening a schema's data item name to a 6-character name that la 
FORTRAN-comps tlble) , as well as any other user- specif Ic format 
Information such as different data type (e.g., converting an Integer 
type to a character type), size (e.g., truncating unneeded decimal 
digits), or relationships (e.g., a different sort order for records). 


1.2.2 The subschema ahall specify a mapping from the appropriate 
schema entry(s) to the corresponding subschema entry(s). The ADAM 
System shall perform this mapping w'^ienever a using program specifies 
that subschema, either during compilation of the program or at run 
time [JHHS 80]. 


1.2.3 The ADAM shall also be capable of automatically mapping any 
subschema Into the corresponding date definition commands of the 
using program's host language (e.g., FORTRAN, PL/I; etc.). 


1.2.4 Changes to the schema another subschema should not require 
modification of any subschema containing unchanged data Items, nor 
the recompilation of programs unaffected by those changes. 


1.3 P£fIKE, AM JB.RI FY PHI.S1CAL MIA BIRUCTyBE 


The physical structure of the data base refers to the actual 
location of various data Items on secondary or tertiary storage 
devices such as tape, disk, or mass store. This structure, which is 
usually specified by the DBA, should be independent: s,£ the logical 
structures of the schema and subschemas, with ADAM responsible for 
mapping from the schema to the physical structure. This explicit 
mapping by ADAM Is analogous to the implicit mapping from the list of 
variables In a READ statement In FORTRAN to the Items of its 
corresponding FORMAT statement. 


Mechanisms for specifying, displaying, modifying, recompiling, and 
verifying the correctness of the physical data structure shall be 
provided, either as part of the data dictionary or independently, and 
preferably separated into the following two functionally distinct and 
Independent specifications: 



1.3.1 Tho physical storage organization specifies physical storage 
characteristics which affect ADAM performance and resource 
utilization but which are not Impacted by a change of storage media. 
These characteristics include, for example, any pointers used to 
relate records, blocks, or sets (Function 1.3. 1.1); whether an item 
is actually stored in the data base or is a ’’virtual'* data item that 
may be calculated from other items whenever it is needed (thereby 
saving storage) (Function 1.3. 1.2); and any constraints on physical 
contiguity of certain data items such as the stored sort order of 
records or the need to have records in a set located together in an 
area (e.g., a block or page) (Function 1.3. 1.3). 

1.3.2 The physical device format and protocol specifies physical 

storage characteristics which are peculiar to a particular storage 
device. These characteristics Include, for example: any device- 

specific or media-specific parameters or formats such as sectoring 
and block-size or track-size (Function 1.3.2.1); and addressing 
mechanisms such as Indexes, hashing and collision- resolution 
algorithms, overflow handling, and standard access mechanisms (such 
as Indexed sequential) provided by the operating system (Function 
1 . 3 . 2 . 2 ). 

1.4 DERIMB,. AM IfiJJFY INfPBMATPW A3Q.II.1 MIh JASES 

The data dictionary and catalogs are bases of information about the 
data base that facilitate the use or alteration of the data base. 
The data dictionary and catalogs are, therefore, themselves, data 
bases which should be structured and stored in machine-readable form 
by ADAM in order to enable a user or the DBA to answer questions such 
as: "What files contain data generated by a synthetic aperture radar 

(SAR) sensor?", "What files contain data pertaining to sea sr*'face 
temperature?", "What user application programs access data item Y?", 
"What users are authorized to access file Z using subschema S?", etc. 

Mechanisms shall be provided for specifying, displaying, modifying, 
and verifying the correctness of information contained in the data 
dictionary and catalogs, as well as their structure (schemas). The 
Importance of this information dictates that the normal security and 
integrity constraints (Functions 1.1.3, 1.1.5) must be specifiable at 

the file, record, and data item levels. 

1.4.1 The data dictionary shall be capable of specifying the 
characteristics of all entitles that impact the data base, to 
Include : 

0 Data items, records, arrays, and other aggregates of data 
contained in the data base. 

o Schemas, subschemas, and physical data structures (both 
physical storage organization and physical device 
format/protocol) that structure the data base, and any 
integrity or security constraints on items contained in 
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theae apeclf Iclatlons. 

o Data aourcea, auch aa aenaora, principal invaatigators), and 
documenta 

o Data producta that are output from the data baae, auch aa 
mapa, new filea, and reporta, overviewa, atatiatioal 
aummarlea, cataloga, aample data, etc. 

o Uaera of ADAM, including modulea, programa, and entire 
ayatema which uae ADAM, aa well aa the humane which Initiate 
theae routinea 

o Tranaactiona which may Impact the data baae, auch aa 
particular eventa or typea of eventa. 

1.^1. 2 The data dictionary ahall be capable of apecifying .any 
relationshlpa which exist between the data base entities identified 
in Function 1.4.1, including (but not limited to): 

o X accesaes Y (e.g., module X accesses data item Y) 

0 X belongs X (e.g., schema X belongs to file Y) 

o X uses Y (e.g., program X uses subschema Y) 

o X Y (e.g., sensor X generates data item Y or 

program X generates product Y) . 

1.4.3 Data catalogs serve two major functions: (1) general top- 

level annotation of the data base, describing how the data in the 
data base was processed, how good it is, when and how it was 
collected, from whom it was obtained, etc., and (2) abstraction of 
the data itself, such as number of data points., ranges or other 
statistics that characterize the values, subsets of the data that are 
typical or of high interest, etc. 

1.5 LOAD. J/JiLQAb AJib APPEND NEW DATA 

Once the data base structure has been correctly defined by Functions 
1.1 through 1.4, users must be able to efficiently load, unload, and 
append data fijj masse into and out of the data base. This function is 
distinct from the "Input Data" function (Function 3.1) in that it is 
used to establish the contents of a new file of the data base or 
append additional blocks of data to that file, rather than 
selectively adding data to an established file. Furthermore, the 
load/unload/append function is intended for manipulating large masses 
of data, which ia.aj£ already conform to a schema (e.g., an image that 
was "destaged" or unloaded from secondary to tertiary storage), 
whereas the input function is intended for smaller quantities of data 
such as a few records. 
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The ADAM Syat$;iin must ue able to accept and loau data In widely 
varying formats. Therefore, as part of the data 
loadlng/unloadlng/appendlng process, ADAM should be able to reformat 
the data automatically to fit the schema and the physical data 
structure (Function order data records to conform to that 

specified in the schema or physical data structure (Function 1.5*2), 
ensure the quality of the data by enforcing Integrity constraints 
specified in the schema (Function 1.5*3)i establish any relationships 
dictated by the schema or application programs performing the load 
(Function 1.5.^), and establish whatever control information or 
delimiters are dictated by ADAM or a file's physical device 
format/ protocol (Function 1.5*5)* 


2 . Minim AM mUB£I MIA 

The ADAM System must be capable of maintaining and protecting the 
data and Information In the data base. Many If not all of these 
functions should be Invisible to most uners, but are essential to 
helping the Data Base Administrator (DBA) to manage the data base 
effectively and efficiently. Besides protecting the data base from 
unauthorized or inadvertent destruction or altera^tion, ADAM should 
provide mechanisms for monitoring and controlling system performance, 
costs, and resource utilization. 

2.1 PROTECT DATA (SECURITY) 


The DBA shall be provided mechanisms to restrict and authorize 
selectively all access to the system, the data base, or, to certain 
system functions. Security Is neo>;ssary to assure privacy for some 
private data files whose owner does not yet wish to share his data, 
for example a principal Investigator's preliminary results which have 
not yet been published or a file of observations which are undergoing 
"cleaning" and other processing. The DBA should be able to grant 
individuals or programs only those privileges whloh they need and no 
more, but he should also be able to delegate his authority 
selectively to responsible users. 

2.1.1 Access to ADAM shall be restricted for security as well as 
accounting purposes, using a user-chosen password or similar 
mechanism. 

» 

2.1.2 Access to files for various purposes (e.g., load, Input, 
modify, delete, or find and access data) shall be llmltable depending 
upon the individual or program requesting such access. Such 
restrictions should be contained In and enforced by a secured portion 
of each subschema (Function 1.2). 


2.1.3 Use of certain ADAM commands shall be 
his designee. For example, many users 
restricted to a "read only" set of functions, 
copy data without altering It. 


llmltable by the DBA or 
should be able to be 
allowing them to use or 
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2.2 fEBFQRM Bmtff Am 


The ADAM Buat faollltate the bulk copying of portiona of the database 
from vulnerable but faat storage media such as main meBory and disk 
to less vulnerable but slower storage media such as tape, and vice 
versa. Such backup and recovery procedures, including the 
restoration of changes made to the data base since the last backup 
was Bade, are necessary to prevent the catastrophic loss of data or 
prolonged system inoperability. In addition, logging earlier 
versions of the data base and those changes that are made to it 
enables the detection and correction of erroneous changes as well as 
unauthorized system operations. 

2.2.1 For event-driven data bases, where updates are made "in place" 
rather than as complete revisions of large portions of the data base, 
the ADAH System shall be capable of supporting: (1) an audit trail 
of all system events or transactions; (2) a copy of the contents of a 
record before it is changed (a "before- image") ; and/or (3) a copy of 

.the contents of a record a fter it is changed (an "after-image"). 
Catalogs and files of altlmetrlc observations undergoing "cleaning" 
'are examples of these types of data bases that are updated record-by- 
record. 

2.2.2 The ADAM System shall provide utilities to backup (or "dump") 
files selectively by copying them to another medium (usually tape) 

And to reverse that process in order to restore files which 
have been damaged. This shall be accomplished without affecting 
other, unrelated files. 

2.2.3 Automatic recovery of the data base to its correct state prior 
to a failure shall be provided through the use of the restore 
function (Function 2.2.2) and one or more of the auditing functions 
(Function 2.2.1). 

2.2.4 The ADAM System shall be capable of enforcing system-wide 
checkpoints (or "quiet periods") at which time the system status and 
memory contents may be preserved in case of system failure (e.g., 
power failure or operating system "hangup"). Conversely, ADAM shall 
be capable of automatic restart of Interrupted processes from the 
last checkpoint, Including "backing out" any changes to the data base 
since that checkpoint. These capabilities are needed in near-real- 
time applications or applications with a large Interactive user 
population where systea failure may otherwise result in unacceptable 
"down" time or the loss of interim results from long operations. 

2.3 £iSM£ data M££ QUALITY 

The ADAM System must provide ways to ensure the correctness of values 
that Individual data items take on, to ensure the consistency between 
values of various related data items, to control the timing of access 
to the same data by multiple users, and to enable users to define 
their own, more complicated quality control procedures that are 
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autoBatloally invoked by the eystem. The advent of distributed data 
baaes requires additional oonstruots to ensure the oonsistenoy and 
Integrity of data at various nodes of a network [FONG 80]. 

2.3.1 Diverse oonstruots to cheok the values of data items are 
essential. Tnose inolude: 

o Hays to validate that data values are of the oorreot type 
and formatf e.g., are not non-numerio oharaoters to be 
inserted in a numerio variable or too long to fit within th«H 
spaoe defined for that data item. It is highly desirable 
that the user be able to speolfy this format using a 
"template" or mask at the oharaoter or bit level, as with 
the PICTURE attribute of PL/I, as well as by speolfylng a 
field or variable "type" (Funotlon 2.3*1*1)i 

o Ranges or enumeration of legitimate values, whioh may be 
speolfled in a designated table (Funotlon 2.3*1 t2); 

o Limitations on what operations may be performed on a data 
item or file (e.g., forbidding any ohanges to a field 
oontalnlng spaoeoraft time) (Funotlon 2.3*1 *3); 

« 

o Constraints on transitions of a data item whioh relate its 
new to its old value (e.g., new value should not be 
different from old value by more than 10)0 or its existenoe 
to its nonexistenoe (e.g., to differentiate between new 
observations and revisions of old observations) (Funotlon 
2.3*1 .i)) ; 

o Ways to ensure that key fields that require unique values 
are in faot unique, Inoludlng ways to re.solve collisions 
(Function 2. 3. 1 .5 ) . 

2.3*2 A data base is distinguished from a set of files by the 
relationships that link data items to each other, forming a whole 
that is greater than its parts. However, the strength of the data 
base concept lies in utilizing the inter-relationships to help locate 
related data and to cross-check related items against each other. 
Therefore, ADAM must be able to validate data items by comparing them 
to related items. The possible classes of comparison are: 

(1) type or domain (e.g., units of measurement must be 
similar) ; 

(2) an expression relating values of more than one data item, 
possibly in different records or even different record 
types (e.g., the distance between the locations of two 
observations must be less than the product of the 
platform's ground speed multiplied by the difference of 
the times of observation); and 

(3) an expression relating a data item and a data aggregate 
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(e.g., an altlmetrlo obaervatlon nust not differ from the 
running average of such observations by aore than 2,5%)» 

The last two relationships nay be enforced by ADAM by providing 
automatic "hooks" or "triggers" to execute user-defined chec^^’lng 
routines (see Function 2.3.4). 

2.3*3 The DBA or authorized user must be able to control the timing 
of the enforcement of the integrity constraints described above, ai» 
well as sharing of data by multiple simultaneous users. These' 
controls shall Include the ability: to temporarily turn e constraint 
on or off (Function 2. 3*3.1); to enforce Immediate or deferred 
changes to a data base depending upon the application (Function 
2. 3*3*2); to specify whether access to a file shall be unrestricted 
(SHARED), a mixture of many read-only accessors and one updating user 
(PROTECTED), or limited to only one user (EXCLUSIVE) (Function 
2.3*3*3); and whether a file Is intended for reading only (RETRIEVAL) 
or may be updated (RETRIEVAL/UPDATE) (Function 2.3. 3. 4). 

2.3.4 The DBA or authorized user should be able to define quality 
control routines which may be written In a programming language and 
which will automatically be Invoked whenever an attempt Is made to 
update the affected data Item(s). This capability may be used In 
conjunction with any of the quality control functions described 
above . 


2.3*5 Enforcement of the above logical Integrity checks may affect 
the Integrity of the physical access mechanisms (e.g., pointers, 
indexes) of the data base. Therefore ADAM should automatically check 
and update these mechanisms if necessary. 


L.0.fiJC.AL, ^ T D M GE 


The ADAM System should monitor and control the overall use of all 
storage over which it has control Including virtual storage assigned 
to It by the operating system, In units meaningful to its internal 
structure. These units may be different from the units which are 
meaningful to the storage devices themselves, the control of which 
constitutes a separate function (Function 4*2.3)* For example, the 
ADAM may be required to store all data in standardized logical 
formats [GRNB 61] that may map Into physical pages of memory In 
complex ways. Additionally, the ADAM shall be capable of controlling 
the migration of data sets among various storage devices for 
performance or other reasons. Examples of this migration Include the 
certification of a data set as suitable for exchange and the control 
of changes to certified data sets (Function 2.4.1), automatically 
staging frequently used data from tape or mass store devices to disk 
(Function 2.4.2), and retiring old or seldom-used data to archives or 
even long-term storage (Function 2.4.3). 
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2.5 MMIIQII MSL IM£ Sl&lM PfiltFQJtHAKCI! 

The ADAM ahit\ll be capable of Bonltoring In real tlae Ita own 
perfornanoe and reporting this to the necessary accounting funotiona 
(Function 2.6) and periodically to the DBA. It shall also perait the 
DBA to adjust major system parameters easily so that system-wide 
trade-offs can be assessed and performance can be Optlmixid. Factors 
to be measured and controlled by this function include: 


o Response time to each user query or oommandf to operating 
system commands, to telecommunications commands, and to 
commands to the input/output (I/O) devices 

o Utilization of I/O channels and devices 


o Utilization of main memory, secondary storage, and tertiary 
storage (if any), including percent remaining and percent of 
storage used for ADAM overhead (e.g., pointers, delimiters, 

etc , ) 


o 


Utilization of the central processing unlt(s) (CPU), both in 
raw seconds and also relative to I/O utilization 


o Percent of data physically retrieved that meets the logical 
retrieval criteria, l.e., the proportion of all data records 
retrieved that are "hits". This factor is important to 
adjusting the granularity of physical storage blocks/ pages 
(see Function ^1.2.3) 


2.6 .mum .C.Qg..T E^nHA I E S AM ACCOUNTING 

2.6.1 The ADAM System should be able upon request to estimate for a 
user, the approximate cost of performing a function before proceeding 
to do it. This estimate shall Include approximate elapsed time to 
retrieve (order of magnitude, e.g., seconds, minutes, hourr) and 
volume of output (e.g., number of data points, tapes, paries of 
printed output). These and the dollar cost can be estimated based 
upon historical data on similar operations, the parameters specified 
by the user, and Information about the data base that is available 
from the data dictionary and catalogs (Function 1.4). 

2.6.2 Utilizing the Information collected by Function 2.5, ADAM shall 
determine a cost that may be charged the user and shall deduct that 
amount from the user's account in a file of accounts maintained by 
ADAM. The user should be able to specify a maximum cost for any 
requested operation (particularly a large data retrieval request) and 
to have the cost to date reported to him. Periodic reports of the 
status of all or selected accounts shall be made by ADAM at the 
request of the DBA. 
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3 


ACCiaa AM MAMlfULATE 8ELECTM MIA 


Th« ADAM Syst«a aust provlda aeohanisas tbafc perait uaers to aooasa 
and aanipulata only tha data in the data bast that aatiafiea their 
iaaediate neada. All othah aajor functions aay be viewed as 

supporting tha goal of this function, which is to get selected data 
to and froa tha user, froa and to tha data base. Selectivity is 
straasad bacauaa tha user gains nothing in perforaanoe by 
centralizing all data under the control of the DBMS unless the DBMS 
oonooaaitantly iaproves tha efficiency of tha access aechanisas to 
that bigger aaas of data. Users aust be able to access and aanlpulate 
Bultipla data bases, plus other files not created by ADAM, 
siaultanaously . 

3.1 mm MIA 

The ADAH Syatea shall facilitate the addition of new data to the data 
base in accordance with the foraat, integrity, and security 
constraints previously established. This data may rone from input 
files in a variety of formats, from user application programs that 
have generated new data or processed data from the data base into a 
new form, through the teleconnunioa tions interface, or from users 
keying in data at their terminal. 

Though this function is distinguished from the load and append 
operation {Function 1.5) in that it is intended for smaller amounts 
of data that are added to an established data base, the two functions 
nonetheless share two common supporting functions: ensuring data 

quality (Functions 3*1*3i 1*5*3) and establishing the necessary 

relationships between the new data and other data items (Functions 
3*1*6, 1.5*A)* In addition, the user must be allowed to find the 

appropriate location to insert the new data (Function 3*1*1t of. 
Functions 3.2.2, 1.5*2), display the data before entering it into the 

data base, and alter the values of the input data items (Function 
3*1.2) if need be before inserting the record into the data base 
(Function 3*1*4). This is accomplished by iMndlng the appropriate 
information about that item (see Function 3.2.1) and formatting the 
data suitably (cf* Function 1.5.1). Finally, any access mechanisms 
such as Indexes must be updated to reflect the changes caused by the 
insertion of the new data into the data base (Function 3*1*5)* 

3*2 FIND AlUi ACCESS DATA 

A key user requirement is the need to find the desired data in the 
data base, and retrieve it for further processing [FJMT 81]. The 
ADAM must therefore permit the user to specify what data is desired, 
help him or her to determine what data is available and possibly 
modify the request, find the actual location(s) of relevant portions 
of the data, retrieve the necessary portions for transfer to the 
user's work area, and eliminate Irrelevant data while reformatting 
the data into the user's view (subschema). 
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3«2«1 Ntohfitnlsiis for finding and aooessing Infornatipn about tha data 
baaa that i» oontained in the data dictionary and catalogs are 
requirad bo helb the user deteralne what data is avallablCi what its 
forpat ist who is authorlaed to use it^ and other charaoterlstios of 
interest to hip. This function pay be aocospllshed by (recursively) 
using Function 3*2 applied to the data dictionary and catalog data 
bases with at least the functions oopprising Functions 3.2,2 and 
3.2.3. 

3.2.2 The ADAM Systep shall find the location of the data requested 

by a user without retrieving the data Itself, so that the user can 
assess the quantity of data satisfying a query and possibly narrow 
his query. The query pay be specified as any copbination of 
relations on either key or non.^key data Itep values (e.g,, sensor s 
SAR, or sea surface height less than 4.5 peters) ranges of values for 
an itep (e.g., latitude between 30H and 40N)» a list of values for an 
itep (e.g., sensor mode * 1r2,4t7i15)r or any copbination of the 
above (Function 3. 2. 2.1). These relations pay be joined by 
conjunction (AND) and/or disjunction (OR) (Function 3. 2. 2.2). The 

systep shall perform the search based upon the appropriate access 
poohanisps (if any) such as Indexes or hash functions that have been 
established for the keys used and for the values specified (Function 
S.2.2.3). Finally, the data base itself shall be searched, if 
necessary, to find the requested data (Function 3. 2. 2. 4). Search 
ptk'ths will be optimized by ADAM to locate the desired records most 
efficiently, e.g,, key items should be searched upon before non^key 
items. 

3.2.3 once the data requested has been found, the ADAM shall retrieve 
the portion needed by the user. This Includes possibly staging the 
data to on-line storage and transferring the selected data to an 
ADAM-admlnlster ed buffer (Function 3. 2. 3.1), selecting the desired 
subset of records (Function 3. 2.3.2) and attributes (fields) within 
each record (Function 3. 2. 3. 3), and then reformatting the remaining 
data to fit the user’s view (Function 3, 2. 3. 4). 

3.3 REARRANGE/ AGGREGATE DATA 

The ADAM System shall support the rearrangement and the aggregation 
of selected data records. This function is distinguished from the 
modification function (Function 3.4) in that it does not alter the 
basic content of the data base, but merely re-orders, merges, or 
summarizes it to enable the user to access and/or understand the data 
more readily. 

3 . 3.1 Some users may wish to re-store data in an order different from 
the order in which the data are stored according to the schema. 
Therefore ADAM must be able to sort data that is selected by the user 
on either key fields (Function 3 . 3. 1.1) or other, non-key fields 
(Function 3 . 3 . 1.2). For example, a file of several Images might have 
different spectral bands interleaved on a row-by-row basis, whereas 
the user wishes to store or process complete images (all rows) from 
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•aoh ap«otr«l band aeparataly* Or, a flla of altiaatrio obaarvatlona 
■ Ight ba atorad in ohronologioal ordar bub fcha uaar wlahaa to 
intarpolata thalr valuaa in latituda/longituda ordar* Onoa thia ra- 
ordaring haa baan aoooBpliahad, uaara aay wiah to aarga two filaa 
baaad upon aiailar or *naar" vaXuaa of a kay or othar fiaXd which 
both fllaa hava in ooaaon (Fuiiotion 3. 3. 1*3). Por axaapla, uaara 
oftan want to ooapara aynoptio obaarvationa of tha aaaa gaophyaioal 
phanonanon by two diffarant aanaora for tha purpoaa of validating 
ranota aenaing taohniquaa CFJHT 81]* Thia would involva warging tha 
filaa or obaarvationa frow tha two aanaora whanavar tha latltuda, 
longltuda, and tiwa wara all "naar** to aach othar within aosa uaar« 
apacifiad tolaranoa. Aa a aubaat, thia warga function ahall inoluda 
tha "JOIN*' function raquirad for a ralational-nodal data baaa. 

3*3*2 Some uaara require only an overview of tha data, at laaat 
initially, i.a,, a view of tha data at lower raaolution than that at 
which it waa collaotad and/or atorad CPJMT 81]* For example, uaara 
often wiah to display an entire 102^ x 1024 pixel image on a 512 x 
512 pixel screen, requiring a 2 x 2 averaging of pixala. Soma 
applioationa require one observation par 1 degree square for data 
collected from a variety of senaora, each having a diffarant 
resolution. Hence ADAM muat be able to aggregate records to tha 
appropriate resolution for the application. This function may 
include user-specified routines for averaging, interpolating, and/or 
resampling. 

3*3*3 In support of the previous function aa well aa many other 
functions, the ADAM should permit the uaer to substitute a 
mathematical expression involving one or more data items wherever a 
data item may be specified. In the previous function, for example, 
the uoer should be able to average the square of an observation as 
easily as he can average the observation Itself. Therefore, tha ADAM 
must support the ability to recognize, parse, and perform 
mathematical expressions that use the basic operations of 
multiplication, division, addition, subtraction, and exponentiation 
upon data items from the data base. 

3*3*4 In addition to the basic mathematical operators, mathematical 
expressions shall also permit the use of certain built-in functions 
similar to those of standard programming languages. Availability of 
these funot'lons in ADAM will allow the user to specify a richer 
variety of expressions and will save the user calling a user-written 
routine to calculate the value of these more complicated expressions. 
Examples of these built-in functions include: 

o Minimum (MIN) of an array (any dimension) of values or all 
selected Instances of a data item or expression. 

o Maximum (MAX) of an array of values or all selected 
Instances of a data item or expression. 
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o COUNT of Boleotod Inatanota of a data Itaa or 

axpresaion. 

o TOTAL of an array of valuta or all atltottd inatanota of a 
data Itan or txpreaalon. 

o Avtrage (AVG) of an array of valuta or all atltottd 

Inatancea of a data Ittn or txprtaaion. 

o Standard deviation (STD DEV) of tht abovt avtragt, 

o Logarlthna (LOG) baat "t” and baat 10 of an txprtaaion. 

o Abaolute value (ABS) of an expreaalon. 

0 Exponentiation (EXP) baat "t” of an txprtaaion. 

o Trigonometric funotiona (SZNt COS, etc.) of an txprtaaion. 

o A aubatrlng (SUBSTR) function, almllar to that of PL/I, for 
facilitating character atrlng aearchlng and manipulation. 

3. 3*5 Uaera ahould be able to define functions that can be Invoked 
at least at the program Interface level, and preferably at the 
command language level too. 

3.^ MIA 

This function la Intended to permit the alteration of the contents of 
aelected data Items, Including bulk updates of many records using a 
single command, as veil as update-ln-plaoe of single records that are 
atored on storage media which permit it (e.g., disk). Examples of 
this latter function Include the correction of an observation based 
upon Interpolation of surrounding values, and the updating of catalog 
entries , 

3.4.1 The data item(s) to be changed must first be located and 
accessed. See Function 3.2. 

3.4.2 New values may be calculated, possibly using the mathematical 
operators (Function 3.3.3)> the built-ln functions (Function 3*3. 4)i 
the old value, and/or user-defined routines (Function 3*3.5). 

3.4.3 Before the new value may become part of the data base. It must 
be checked automatically for quality based upon Its entry(a) In the 
schema or subschemas. See Function 2.3* 

3.4.4 The new value(s) may now be atored, either by Inserting the 
modified record into a new location found for It, by overwriting the 
old value(s), or by writing the Item to an output file that 
constitutes the updated version of the file. 
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If old valuta «ra not ovarwrlttarii thay nay need to be 
deleted. 

3*4.6 The aodlfloetlon of key flelda nay affeot the aooeae 
neohanienCa) uaed to find that data iten (e.g., Indexeaj pointers, or 
hashing functions). Therefore, these aooess neohanlsms should 
autonatloally be oheoked and updated by ADAM If necessary, 

3 *''*7 The nodlfloatlon of any data Iten nay affeot the 
relatlonshlpCs) It shares with other data Itens, as specified In the 
sohena, aubsohena(s), and/or pointer fields. Therefore, ADAM should 
autonatloally check and update appropriately these relationships In 
order to ensure the Integrity of all relationships. 

3.5 JPELETfi MIA 

The user should be able to delete, or Riark for later deletion, any 
Instance of a data Iten, record, file, etc., subject to the 
constraints Inposed by the sohena or subschema upon the data and/or 
the user (See Function 2.1.2). 

t 

3.6 PREPARE JJAIA £M OUTPUT 

* 

The ADAM shall have neohanlsns for specifying the logical structure 
of various types of outputs. Independent of the physical format 
details for a particular device. For example, a tabular arrangement 
of data prepared by this function should be unaffected by the need to 
display It on a Hewlett-Packard terminal Instead of a Tektronix 
ternlnal. Adaptations of that sort are the concern of the Interface 
to the operating system (see Function 4.2.2), which ultimately 
oonnands the devices In machine language. This function shall 
Include both prior definition and naming of a data product format in 
a schema and/or subschema (see Functions 1.1 and 1.2) and jaul hoc 
specification by user commands (e.g., "DISPLAY...”). 

3.6.1 As part of the specification of an output product, the user may 
wish to rearrange or aggregate the data temporarily according to his 
own view of the data (his subschema) or in an order peculiar to that 
particular output product. This function is different from Function 
3.3 in that It results In no change to the data base. The ADAM shall 
pernlt the user to specify the appropriate d'^ta Item(s) or 
expresslon( s) on which to order or aggregate the ou^uput, Including 
nested orderings (e.g,, "... ORDERED BY SC. TIME BY LONGITUDE" or 
"AVERAGED BY SC.TIME, BY LOCATION"). See also Function 3*3. 

3.6.2 The usual basic report- writing constructs shall be provided. 
Including the ability to specify titles for page headings, footings, 
rows, colunns, subtotals, and totals (Function 3*6. 2.1); the ability 
to space columns (Function 3*6. 2. 2) and rows (Function 3. 6. 2, 3) 
autonatloally on the page In a way that enhances readability; and the 
actual fornattlng of each page, including the determination of how 
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Buoh to fit In a single page, overflow bo subsequent pages, and page 
numbering (Function 3.6.2.<l). 

3*6.3 As an optional enhanoement to the basic system, the ADAM shall 
permit the user to format graphs formed from the data selected from 
the data base or provided by the user. This graphing shall include 
the specification of titles for the graph and labels for the axes, 
points, keys, etc. (Function 3. 6. 3.1); the determination of the 
scale, endpoints, and any breaks In the axes of the graph, either 
ar tomatloally from the data to be graphed (defa'ult) or manually 
specified by the user (Function 3*6. 3*2); and the actual plotting of 
points, vectors, curves, characters, etc., derived from the data 
provided (Function 3. 6. 3*3). This capability shall Include the 
plotting of data versus location on various maps, either as symbols, 
numbers, or contours. 

3*6.4 As another optional enhancement to the basic system, ADAM shall 
enable the user to prepare for display raster Images using data 
extracted from the data base, provided by the user, or generated by 
another ADAM function (especially graphics outputs. Function 3*6.3). 

3*6*5 In order to transfer a block of data to another program within 
the system, par t1.oularly a user's application program, or to another 
system, the ADAM must be able to specify formats for 
telecommunications packets (Function 3. 6*5*1) or physical storage 
structures (Function 3. 6. 5*2) that are compatible with the format of 
the destination. 

3*6.6 For applications where users interact directly with ADAM, the 
specification and preparation of screen displays for cathode ray tube 
(CRT) devices Is required as an optional enhancement to the basic 
system. This function shall adapt the outputs of Functions 3*6.2 
through 3*6.4 for screen display and response by users. Including: 
any special screen titles (Function 3. 6. 6.1); reformatting of data or 
output products for screen display (Function 3*6. 6. 2); adding any 
borders or templates needed for forms or other display enhancements 
that aid user comprehension (Function 3*6*6. 3); permitting the user 
to scroll through to any page of an output product (Function 
3*6. 6*4); formatting a "menu" of potential user responses to the 
display (Function 3. 6. 6. 5; of. Function 4. 1.1*1); and accepting user 
responses (Function 3. 6*6. 6). 

3*6.7 Users must be able to name and store output products for 
subsequent retrieval and/or transfer to ether devices. 

4* imBf.ACfi Kim QjMR ^ ocRAMg 

The ADAM shall provide Interfaces to all other system programs with 
which It must deal. In a centralized and modularized fashion. These 
programs shall Include, but not be limited to, user application 
programs or query programs, the operating system or executive 
program, and data communications control programs. If any. For more 
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details on the sequence of how these programs Interact, see [CDSY 7 I, 
CRDN 79]* It Is assumed In the discussion which follows that the 
reader Is familiar with language compilation/ interpretation and with 
how system programs Interact with each other, I/O channels, and the 
hardware. 

i|.l INTERFACE WITH U^ER APPLICATION/QUERY PROGRAM -; 

The ADAM shall be able to Interface to user's application or query 
programs, either by being invoked by the user program and/or by 
Invoking the user program from ADAM environment. Application 
programs are differentiated from query programs (or simply "queries") 
here by two major factors: 

^ Queries are generally jgsL in nature, to be used only once, 
whereas application programs (once debugged) may become 
operational routines. 

° Queries are usually generated Interactively with each command 
translated and verified as It is entered (l.e.. Interpreted), 
whereas application programs are frequently submitted as 
programs which are translated £ji ga sse before execution 
( l.e. , compiled) . 

Although thlJ distinction between queries and application programs 
dictates that they be separated functionally, many of their 
supporting functions are similar and It Is highly desirable that they 
share a common command syntax so that users need learn only one data 
manipulation language [JHN5 80]. 

4.1.1 Due to the interactive nature of queries, the query processor 
must perform several functions which help the Interactive user. 
These include generating user prompts, preferably Including a menu of 
actions from which the user can choose (Function 4. 1.1.1, see also 
Function 3 . 6 . 6 ); storing and displaying upon request user HELP 
routines which explain In more detail the use and syntax of a 
particular ADAM command (Function 4. 1.1. 5); and maintaining the 
continuity of the dialogue with the user by optionally providing 
status Information every 5 to 10 seconds during long operations 
(Function 4. 1.1. 4). The latter function helps to prevent the user 
from becoming Impatient with the system or from suspecting that the 
system has forgotten about him. The user must be able to cancel a 
request at az,iy point during a long operation without loss of data 
base integrity or loss of data retrieved up to the cancellation. It 
should also be noted that .ADAM should provide only the constructs for 
building user menus, not the menus themselves: that is an 

application-specific output product that should be tailored to the 
user by each organization utilizing the ADAM. However, certain 
application-independent menus could also be built Into ADAM using 
this same facility. 
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Functions which the query processor shares with the application 
program interface include: translating user commands in an ADAM 
language into a function to be invoke<^ ^nd the parameters needed by 
that function (Functions i|.1.1.2| transferring ADAM control 
to the appropriate funotion(s) (Functi? ns i».l.l,3, 4. 1.2. 2); and 
g ,arating error messages, diagnostics, or return codes to the user 
ii* Inform him of the status of his query (Functions 4. 1.1. 6, 
^i.1.2.5). Several levels of error severity should be supported, 
including advisories, warnings, recoverable errors, and fatal errors. 
Error messages should return both an error number and text stating 
the location of the error (routine name, line and column number-, 
refiord type and key), its severity level, and the type of error 
(syntax, invalid reference, integrity or security violation, I/O 
error, user abort, etc.). 

4.1.2 If ADAM Interface to application programs is via "CALL** 
commands within the application program, then the translation 
function x'or this interface (Function 4. 1.2.1} is simplified: the 
program's host language will pass to ADAM the function and all 
qualifying parameters (e.g., data item names or expressions, options, 
etc.) as parameters of its CALL command. Otherwise, ADAM must parse 
the "stand-alone" ADAM-language commands Just like any other language 
translator (compiler or Interpreter). Since it is desirable that the 
application program interface use the same high-level language as the 
query processor, DBMS commands will be Interspersed among host 
language commands. This implies the need for either: (1) a superset 
of standard programming languages that contain ADAM commands, or (2) 
a pre-compiler to convert ADAM commands to CALLS in the host 
language . 

Because application programs will be potentially passing large 
amounts of data between it and ADAM, ADAM must include the functions 
of accepting data from application programs (Function 4. 1.2. 3) and 
returning data to application programs (Function 4. 1.2. 4), through 
user work areas and ADAM buffers. 

$ 

4.1.3 The ADAM System shall enable the user to build, store, and 
execute "macros" of ADAM commands. Macros are a sequence of ADAM 
commands that are stored as text files under a ref erence able name 
(Function 4. 1.3.1) that permits text substitution (Function 4.1.3-2) 
and execution of the commands (Function 4.1«3>3) by using the macro 
name like a single ADAM command. It is desirable that the macro 
facility include a "call-by-name" substitution of run-time values for 
macro parameters when entering and exiting the macro, as well as the 
ability to loop and branch. 

4.2 XMlEAfAgj; MIIH OPEMim SYSTEM 

The ADAM must Interface with and be under the control of the resident 
operating system or executive program at each installation upon which 
it is Implemented. The operating system controls the interaction of 
programs (including ADAM and its application programs), resource 
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utilization, and all dealinga with the hardware (e.g., Interrupta, 
I/O prioritlea, etc.). Becauae the operating ayatema at varloua 
inatal la tlona will neoeaaarily differ, it la imperative that ADAM 
centralize Ita interface with the operating ayatem into a minimal aet 
of modulea (aee alao the requlreaenta of Seotiona i|.3, and that 

it perform aa many funotlona independent of operatlng-ayatem-apeclf lo 
paraaetera aa poaalble. 

4.2.1 The tranalatlon of ADAM oonaanda into invokable ADAM functlona 

la performed by the uaer interface (Function 4.1). These functlona, 
in turn, muat at aome point execute some machine language commands 
which, for performance purposes, must be tailored to the operating 
system and hardware which execute them. The operating system 
servloea which ADAM will use Include: slngle<-key access methods that 

may be provided as part of the operating system (Function 4. 2. 1.1); 
READ and WRITE commands provided by the operating system that save 
having to write channel command sequences (Function 4. 2. 1.2); and 
virtual memory versions of operating systems that treat secondary 
storage as an extension of main memory and automatically move "pages'* 
of data between the two (Function 4. 2.1. 3). Alternatively, where 
these operating system services are absent or inefficient for DBMS 
applications, ADAM may have, to provide some or all of these services 
[STNB 81]. As operating systems become more powerful and 
sophisticated. Interfaces to other such services may need to be added 
here. 

4.2.2 The interface to the operating system should be responsible 
for mapping the physical storage structures of the data base that 
were defined in Function 1.3*1 into the device-dependent formats and 
protocols that were defined in Function 1.3.2. These formats and 
protocols will therefore be used in generating the specific machine 
language required for any given transfer to another program in main 
memory (Function 4. 2. 2. 5), or for any given access to the data base 
storage devices (Function 4. 2. 2. 4) or any other I/O device. The 
latter includes device-dependent parameters and formats for data 
products, such as reports (Function 4. 2. 2.1), graphics (Function 
4. 2. 2. 2), and Images (Function 4. 2. 2. 3). 

• 

4.2.3 The ADAM Interface to the operating system shall be 
responsible for the monitoring, allocation, and de-allocation of the 
physical storage space that has been allocated to it by the operating 
system, as well as the mapping of logical storage structures if any 
to these physical blocks of data which the operating system 
manipulates efficiently (e.g., pages or disk tracks). Control of 
these physical storage spaces Include allocation and de-allocation of 
buffers for I/O devices and user programs ("work areas") (Function 
4.2«3«1); allocation and de-allocation of blocks, pages, areas, 
tracks, or whatever constructs are used to divide up secondary 
storage (Function 4. 2. 3*2); and periodic collection of free space 
vacated by deleted data items, often called "garbage collection" 
(Function 4. 2. 3. 3)* 
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Aa an optional enhancement to the baalo ADAM system for installations 
having significant telecommunications traffic and for distributed 
data base applications, ADAM should be capable of interfacing with 
specialized programs that optimize data communications resource 
utilization. This interface will need to include the ability to: 
send and receive commands, with the proper synchronization, to and 
from the telecommunications program via the operating system 
(Function 4.3.1); translate commands to and from either a 
standardized network language or the language of the destination node 
(Function 4.3.2); send and receive data to/from the network or a 
program at one of its nodes (Function 4.3«3)i perform necessary 
protocol and synchronization functions (polling, add’^esslng, 
scheduling, queueing, prioritization, authorization of resource 
utilization, security of terminals, and overall control and 
efficiency of telecom muni cations) that are either required by a 
telecommunications program or are not otherwise supplied by it 
(Function 4.3.4); and reformat or packetize commands and data to 
conform to the stand, irds of the network and to individual terminals 
(Function 4.3.5). 


Provide Data 
to Application Programs 
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Figure A-1. Top-Down Functional Analysis of the Functions 
to be Performed by ADAH 
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Ll.4.3 

Data Catalogs 

Figure A-1. Top-Down Functional Analysis of the Functions 
to be Performed by ADAM (cont) 
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Figure A-1. Top-Down Functional Analysis of the Functions 
to be Performed by ADAM ( cont ) 




Parent Function 


ORlGiriAL PAGE fS 
OF POOR QUALITY 



i 


to be Performed by ADAM (cent) 





n 

a 

o 

•H 

*» 

O 

0 

0 

bu 

« 

sx 

ip 



I 

<< 

V 

0 

S) 

■H 

U* 




A-26 


er 



Function 


o o n) 
O 'H iJ 
<; 4 J «a 
nJ Q 

nu 

g 


4 J 

(U 

(0 

3 * 
• u »o 

ro o M 
' 01 o 
CN f-Hi o 

. (U QJ 


u 

Hi 

iO -K 
»o 

•3 W 
<0 0 ) 
u 

f'i *j 3 

• CJ ^ 

<n 0 ) Ih 

• 'n U 
CM O *J 

• M +J 

<n 


tM iH oJ 

ri'.SS 


N 

ca T3 
4j a) 

0 gj 
P vs 


as 


•V 3 

1 eg 

0 O' 

• 

*H as 

n 



rt o 

Ch vs 
O u 
vs 

H *H H 

. I ".>vvi 

*H vs 

C<S U 9 ) 

• td 60 _ 

’51 |A V » 

<n p 9 ^ 


C 9 o o 
» 0 C 
eg 3 3 

• 'P-j •r-j 

^ P os’ 


C a) VS 

^ 3 

• rC m rH 
p > rt 

• M £> 

eg CB ^ 

• 0 ) o g-f 

w {x; o 


vs (d 
> 

M 0 ) 

,0 3 0 ^ 

*H H o 

CD 

»H CO 
•H 0 ) Si^ 

*g <u 

•C 43 3 
p H m 
^ H « 


eg o H 

* M M 

eg « ij 

* 0 ) 4 J 

ei K) <* 











A-29 



Parent Function 



A- 30 


Figure A-1. Top-Down Functional Analysis of the Functions 
to be Perforned by ADAM ( cont) 
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Figure.A-1, Top-Down Functional Analysis of the Functio 
to be Performed by ADAM (eont) 
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Figure A- 1 . Top-Down Functional Analysis of the Functions 
to be Performed by ADAM (cont) 














